LumenWipe performs irreversible operations on Stellar accounts - it removes trustlines, cancels offers, exits DeFi positions, and merges accounts. A security vulnerability could result in permanent loss of user funds. We take this seriously and are committed to addressing security reports promptly and transparently.
- Supported versions
- Reporting a vulnerability
- Response timeline
- Scope
- Out of scope
- Disclosure policy
- Security reviews
- Security design principles
| Version | Supported |
|---|---|
main branch (latest) |
Yes |
| Previous releases | Critical fixes only |
We recommend always using the latest version.
Do not open a public GitHub issue for security vulnerabilities. Public disclosure before a fix is available puts users at risk.
To report a vulnerability, email:
Include in your report:
- A clear description of the vulnerability
- The component affected (see Scope for the list)
- Steps to reproduce, or a proof of concept if you have one
- The potential impact - what an attacker could do and under what conditions
- Your preferred disclosure timeline, if any
PGP encryption (recommended for sensitive reports): a PGP public key is published at lumenwipe.com/.well-known/security.txt.
You will receive an acknowledgment within 48 hours. If you do not hear back within that window, follow up by opening a GitHub issue with the title "Security contact - please check email" and no further details.
| Milestone | Target |
|---|---|
| Acknowledgment | 48 hours after report |
| Initial assessment (confirmed / not confirmed) | 5 business days |
| Status update | Every 7 days while the issue is open |
| Fix for critical / high severity | Before public disclosure |
| Fix for medium severity | Within 30 days |
| Fix for low severity | Next regular release |
We will coordinate the public disclosure date with you. We ask for a minimum of 14 days after a fix is deployed before public disclosure, to allow users to update.
The following components are in scope for security reports:
| Component | Examples of in-scope issues |
|---|---|
| Key handling | Secret key leaking outside browser memory, persisted to localStorage / sessionStorage / IndexedDB / network requests, logged, or exposed in error messages |
| Transaction construction | Operations encoded incorrectly (wrong destination, wrong amount, wrong memo), fee manipulation, envelope tampering |
| Signing flow | User signing a transaction they did not review; auto-submission without explicit user confirmation; multisig signature accumulation leaking a partial key |
| Mediator account flow | Mediator keypair persisted, reused, or sent to the backend; funds forwarded to the wrong destination; memo validation bypass for known exchange destinations |
| Allowance inspector | Incorrect allowance data leading a user to believe an approval was revoked when it was not |
| Content Security Policy | Bypasses that allow injected scripts to execute in the application context |
| XSS | Cross-site scripting that could read the in-memory key or intercept a signing operation |
| Backend read-only guarantee | Any path by which the backend receives a private key, a signed envelope with key material, or can influence a transaction without user awareness |
| Session store | Sensitive data (keys, signed envelopes) written to IndexedDB or any persistent browser storage |
| Dependency vulnerabilities | High or critical CVEs in direct dependencies that affect the signing or transaction construction surface |
| DeFi exit correctness | Exit adapter building a transaction that would drain more funds than the user's position, or skipping a repayment that leaves a protocol in an unsafe state |
The following are not considered security vulnerabilities for this project:
- Vulnerabilities in the Stellar protocol itself, Stellar RPC, or third-party data services (stellar.expert, OctoPos, Orion, Soroswap API) - report those to the respective projects
- Phishing sites that impersonate LumenWipe - report these to us for awareness, but they are not code vulnerabilities
- Denial of service against the read-only backend - the backend holds no funds or keys; disrupting it affects availability, not security
- Social engineering attacks
- Issues requiring physical access to the user's device
- Vulnerabilities in browsers that LumenWipe cannot control
- Self-XSS (the attacker must already control the victim's browser session)
- Rate-limiting bypass on the read-only backend (no funds at risk)
- Missing
Secure/HttpOnlyflags on non-sensitive cookies - Clickjacking where no sensitive action can be triggered in a single click without user review
If you are unsure whether an issue is in scope, report it and we will assess it.
We follow a coordinated disclosure model:
- You report the vulnerability to us privately.
- We confirm receipt within 48 hours and provide an initial assessment within 5 business days.
- We work with you to understand and reproduce the issue.
- We develop and test a fix. For critical and high severity issues, the fix is deployed before any public disclosure.
- We coordinate a disclosure date with you - typically 14–30 days after the fix is deployed, depending on severity and user exposure.
- We publish a security advisory on GitHub with the vulnerability details, the fix, and a credit to you (unless you prefer to remain anonymous).
We do not pursue legal action against researchers who report vulnerabilities in good faith and follow this policy.
Credit: Security researchers who responsibly report valid vulnerabilities are credited in the advisory and in the repository's security acknowledgments.
The codebase undergoes internal security reviews as part of our development process. External security audits will be conducted when possible.
Understanding the security model helps you identify which issues are most impactful. The full model is in docs/architecture.md - Section 13. In brief:
Private keys never leave the browser.
The primary signing path uses stellar-wallets-kit, which means the application never sees the private key at all. The advanced secret-key mode keeps the key in memory only - never in localStorage, sessionStorage, IndexedDB, cookies, or any network request - and clears it immediately after each signing operation.
The backend is read-only and never in the signing path. A fully compromised backend could return incorrect read data, but it cannot sign transactions, move funds, or access keys. Wrong read data is defended against by on-chain simulation and explicit user confirmation before every destructive step.
Every destructive step requires explicit user confirmation. The tool never auto-submits. Users confirm each step after reviewing what it does, see the XDR, and in the case of the final merge, confirm the full destination address on a dedicated confirmation screen.
The mediator keypair is ephemeral. It is generated in the browser, used once to sign the forward payment, and then nulled from memory. Only its public key is recorded in the session for transparency and recovery.
Strict Content Security Policy.
No inline scripts, no unsafe-eval. Any XSS payload that cannot execute JavaScript cannot intercept the in-memory key or signing operations.