Security Reporting
Security is an important part of building reliable infrastructure.
Senmo Technologies welcomes responsible reports of potential security vulnerabilities affecting our platforms, APIs, and associated infrastructure.
This page explains how to report a suspected security issue, what information to include, and how to disclose findings responsibly.
Our security reporting guidance applies to Infrarails, Hyperhash, Foundry, and other Senmo-operated services within the scope of an authorized assessment.
Report a security vulnerability
If you believe you have identified a security vulnerability affecting Senmo infrastructure, please report it responsibly.
The Senmo Support Desk is our documented support entry point.
If the portal provides a dedicated security reporting category, use it. Otherwise, request a private security reporting channel without including exploit details or sensitive evidence in a general support ticket.
Do not submit sensitive vulnerability details through publicly accessible channels.
What should I report?
Security reports may involve vulnerabilities affecting authentication, authorization, application logic, financial integrity, or infrastructure security.
Authentication and authorization
Examples include:
- Authentication bypass.
- Unauthorized access to API endpoints.
- Privilege escalation.
- Incorrect access control enforcement.
- API credential exposure.
- Cross-account or cross-ledger access.
API security
Examples include:
- Injection vulnerabilities.
- Insecure request validation.
- Sensitive information disclosure.
- Improper error handling.
- Unauthorized resource modification.
- Security-relevant API configuration weaknesses.
Financial infrastructure security
For InfraRails, relevant findings may include:
- Unauthorized transaction creation.
- Transaction replay vulnerabilities.
- Idempotency bypass.
- Unauthorized balance modification.
- Incorrect ledger isolation.
- Accounting integrity vulnerabilities.
- Unauthorized transaction status transitions.
Blockchain infrastructure security
For Hyperhash, relevant findings may include:
- Unauthorized wallet operations.
- Private key exposure.
- Incorrect transaction authorization.
- Digital asset access control vulnerabilities.
- Insecure blockchain integration behavior.
Only assess systems and capabilities for which you have explicit authorization.
Voucher infrastructure security
For Foundry, relevant findings may include:
- Unauthorized voucher issuance.
- Voucher redemption bypass.
- Duplicate redemption vulnerabilities.
- Unauthorized voucher modification.
- Access control weaknesses.
Information to include
A useful vulnerability report should provide enough information for the issue to be understood and investigated safely.
| Information | Description |
|---|---|
| Affected product | InfraRails, Hyperhash, Foundry, or another Senmo service |
| Vulnerability title | Short description of the suspected weakness |
| Affected component | API, endpoint, application, or infrastructure component |
| Severity assessment | Your assessment of the potential impact |
| Technical description | Explanation of the vulnerability |
| Reproduction steps | Minimal steps needed to demonstrate the issue |
| Potential impact | What an attacker might be able to accomplish |
| Supporting evidence | Sanitized logs or proof-of-concept information |
| Discovery date | When the issue was identified |
Include only the information necessary to support the report.
Security report template
Subject:
Security Vulnerability Report — [Product]
Affected Product:
[InfraRails / Hyperhash / Foundry / Other]
Affected Component:
[API endpoint, application, or service]
Vulnerability Type:
[Authentication / Authorization / Injection / Other]
Severity Assessment:
[Critical / High / Medium / Low]
Description:
[Explain the suspected vulnerability]
Potential Impact:
[Describe the security implications]
Steps to Reproduce:
1. [Step one]
2. [Step two]
3. [Step three]
Supporting Evidence:
[Sanitized evidence]
Discovery Date:
[YYYY-MM-DD]
Contact Information:
[Preferred method for follow-up]Before sending exploit code, credentials, or sensitive evidence, confirm that an appropriate private reporting channel is available.
Responsible disclosure guidelines
We ask security researchers and developers to act responsibly when investigating potential vulnerabilities.
Do
- Report suspected vulnerabilities privately.
- Limit testing to systems you are authorized to assess.
- Use the minimum activity necessary to demonstrate the issue.
- Avoid accessing or modifying real customer information.
- Preserve confidentiality while a report is being reviewed.
- Provide clear technical evidence.
- Stop testing if unexpected sensitive data becomes accessible.
Do not
- Attempt to access accounts or data belonging to other users.
- Modify or delete production data.
- Execute unauthorized financial transactions.
- Extract private keys, credentials, or sensitive information.
- Perform denial-of-service testing.
- Conduct social engineering or phishing attacks.
- Publicly disclose exploit details before coordinating with the affected parties.
- Use discovered vulnerabilities to gain unauthorized access or financial benefit.
These guidelines do not grant permission to conduct security testing. Authorization must be obtained separately where required.
Severity classifications
Security vulnerabilities may be assessed according to their potential impact and exploitability.
| Severity | Description |
|---|---|
| Critical | Potential for widespread compromise, severe financial integrity impact, or unauthorized control of critical systems |
| High | Significant unauthorized access, sensitive data exposure, or serious security control bypass |
| Medium | A security weakness with meaningful but limited impact |
| Low | A lower-impact weakness requiring restricted conditions or additional factors |
Final severity depends on technical validation, affected systems, exploitability, and operational context.
How security reports are handled
The intended vulnerability-handling process includes the following stages.
1. Report intake
The submitted report is received through an appropriate communication channel.
2. Initial assessment
The available information is reviewed to determine the affected component and potential impact.
3. Technical validation
Where sufficient evidence is available, the suspected vulnerability is assessed.
4. Risk evaluation
The issue is evaluated according to its potential security, operational, and financial implications.
5. Remediation
Where a vulnerability is confirmed, corrective action may include code changes, configuration updates, credential rotation, or additional security controls.
6. Verification
Relevant fixes are tested to determine whether the identified weakness has been addressed.
7. Follow-up
Where appropriate, the reporter may receive additional information through the established communication channel.
This process describes intended handling and does not establish guaranteed acknowledgement or remediation deadlines.
Confidentiality and sensitive information
Security reports may contain information that could expose systems or users to additional risk.
Please avoid including:
- Live API credentials.
- Passwords.
- Private cryptographic keys.
- Recovery phrases.
- Unnecessary personal data.
- Full customer financial records.
- Unredacted authentication tokens.
If sensitive information is necessary to demonstrate a vulnerability, request a secure communication method before sharing it.
Financial integrity concerns
For InfraRails, vulnerabilities involving ledger balances, transaction authorization, idempotency, or accounting consistency should be treated with particular care.
Do not attempt to demonstrate financial vulnerabilities by moving real funds, altering production balances, or creating unauthorized transactions.
Where possible, provide a minimal technical explanation or evidence from an explicitly authorized testing environment.
If you suspect that a financial operation has already been affected, preserve relevant identifiers and avoid further changes until the issue can be investigated.
Coordinated disclosure
We encourage reporters to coordinate disclosure of confirmed security vulnerabilities.
Public disclosure should be discussed with the affected parties to reduce the risk of exposing unresolved vulnerabilities.
Any disclosure timeline should consider the severity of the issue, remediation progress, and potential impact on users or infrastructure.
This page does not establish a fixed disclosure deadline or a formal safe-harbor agreement.
Security research and rewards
This documentation does not announce a public bug bounty program or financial reward arrangement.
Security research must remain within authorized boundaries.
Do not assume that vulnerability submissions qualify for compensation or authorize otherwise prohibited testing.
Security incidents
If you suspect an active security incident affecting your integration:
- Stop potentially harmful activity.
- Preserve relevant request identifiers and timestamps.
- Protect affected credentials and systems.
- Report the concern through an appropriate private channel.
- Avoid publishing sensitive information.
- Follow the incident-handling instructions applicable to your organization.
If a credential is believed to be compromised, take appropriate containment measures, including credential revocation or rotation where supported.
Related resources
- Senmo Support Desk — Official support entry point.
- Contact Support — General technical assistance.
- Report an Issue — Non-security technical issues.
- Service Status — Service availability information.
- Authentication — API credential requirements.
- API Reference — Supported API operations.
*Senmo Technologies Limited develops software infrastructure. This security reporting guidance does not authorize penetration testing, establish a public bug bounty program, or create contractual security response commitmen
Updated about 4 hours ago