xrpl-dev-portal/blog/2025/vulnerabilitydisclosurereport-bug-sep2025.md

category, date, template, seo, labels, markdown

category	date	template	seo	labels	markdown
2025	2025-09-29	../../@theme/templates/blogpost	description This vulnerability disclosure report contains technical details of the XRP Ledger bug reported on September 15, 2025.	Advisories	editPage hide true

Vulnerability Disclosure Report: XRPL Permission Delegation

This vulnerability disclosure report contains technical details of the amendment Permission Delegation reported on September 15, 2025.

Date Reported: September 15, 2025

Affected Version(s): rippled 2.5.0 to 2.6.0 (with the PermissionDelegation amendment enabled)

Summary of Vulnerability

On September 15, 2025, a bug was identified regarding the XRPL Permission Delegation feature, which allowed an account to charge transaction fees to any other account and could have been maliciously used to drain an account’s XRP balance.

The feature was not enabled on mainnet. Immediate action was taken to advise voting against the affected amendment, and a follow-up proposal is underway to introduce a new amendment with the necessary fixes for a future release.

Impact

The bug was identified in the non-production environment during the amendment's voting phase. The amendment had not yet been activated in mainnet.

Upon discovery, UNL validators began voting “No” as advised, to prevent its activation. The current amendment featurePermissionDelegation will be disabled in rippled 2.6.1 and later, and a revised version featurePermissionDelegationV1_1 will be introduced to replace it. This may potentially slow down the timeline for the feature to go live.

Technical Details

Discovery

On September 15, 2025, tequ (a community member) reported a bug in the Permission Delegation amendment while testing on devnet. The Ripple engineering teams promptly investigated and confirmed the issue. In response, immediate steps were taken to begin remediation and notify the XRPL validator community.

Root Cause

The XRPL Permission Delegation feature allows an account to grant specific permissions to another account, such as the ability to submit certain transactions on its behalf. In such delegated transactions, the transaction fee is designed to be charged to the delegated account.

However, under certain conditions, this transaction fee is charged even if the transaction isn’t properly signed, which can enable malicious actors to drain XRP from another account through these fees.

This behavior occurs only when the delegated account lacks the necessary permissions, and when the transaction is signed offline (i.e. not using rippled). Under these conditions, a malicious actor could exploit the system to impose unauthorized transaction fees, thereby draining XRP from the delegated account.

In the verification process, permission is checked before signature verification. If the delegated account lacks permission, a tecNO_DELEGATE_PERMISSION error is returned before the signature is checked. Since tec type errors are designed to charge a transaction fee, a malicious account can submit a transaction with a high fee and a valid but unauthorized signature. As long as the victim account lacks the required permission, the transaction fails with tecNO_DELEGATE_PERMISSION before checking the signature, and then the fee is deducted from the victim’s account.

This issue can be attributed to two key factors. Ensuring that either one of the following conditions is met would prevent the vulnerability:

• Error Type:

  • tec errors result in a fee being charged.
  • NotTEC errors do not result in a fee.
  • Therefore, any error returned before signature verification must not be of type tec.

• Order of Checks:

  • Validation logic that may result in a tec error must occur after the signature verification.
  • This ensures that no transaction can be charged a fee before the signature has been validated.

Remediation

• UNL validators were encouraged to vote "No" on the featurePermissionDelegation amendment to block activation, and several of them have done so.
• Disabled the amendment in release 2.6.1~rc2 and all the future releases.

Security Enhancements Roadmap

For this specific case:

• The error code tecNO_DELEGATE_PERMISSION has been changed to terNO_DELEGATE_PERMISSION to prevent fees from being charged before signature verification. (This change has not yet been merged and is pending review and testing.)

Ripple engineering teams and stakeholders are also reviewing the broader codebase to help prevent similar vulnerabilities in the future. Planned improvements include:

• Refactoring pre-signature validation logic to ensure that only NotTEC errors are returned before signature verification.
• Adding an invariant check to prevent any transaction fee from being deducted unless the signature has been verified. This will help detect future issues early if any feature violates this rule.
• Additionally, clear documentation and comments should be added to explicitly state that tec errors must not be generated before the signature has been verified.

Steps to Reproduce

1. Construct a transaction where the Delegate field is set to an account that does not have permission to send the specified transaction on behalf of the Account field.
2. Sign the transaction offline to bypass RPC-level signature checks.
3. Submit the transaction to the network.

Expected pre-fix behavior:

• The transaction fails with tecNO_DELEGATE_PERMISSION, regardless of whether the signature is valid.
• A transaction fee is deducted from the delegated (victim) account even when the signature is invalid.

{% admonition type="info" name="Note" %} If you sign online (via RPC), the invalid signature will be caught early and rejected with bad_secret, preventing the exploit path from being triggered. {% /admonition %}

Fixes / Patches Available

The fix for this issue is available on devnet in an updated version of the feature amendment: PermissionDelegationV1_1. You can see the details of the fix here. The new amendment replaces PermissionDelegation and DelegateV1_1, both of which are now deprecated.

Acknowledgements

Thanks to tequ for responsibly reporting the issue, and to the UNL validators for their swift response in confirming and blocking the amendment. Thanks to the engineering teams for their thorough investigation and efforts to strengthen the long-term security of the codebase.

And, as always, thanks to the global community of validators, developers, and contributors who keep the XRP Ledger running and help keep the network safe and secure.

References

• xrpl.org doc: https://xrpl.org/docs/concepts/accounts/permission-delegation
• XLS-0074 Account Permissions
• XLS-0074 Permission Delegation

Contact

For more information or to report further issues, please contact the team at bugs@xrpl.org.

Incident Response Timeline

Key Actions	Timestamp	Description
Initial Discovery	September 15, 2025	Alerted by tequ (a community member) about the vulnerability.
Mitigation Actions Taken	September 15, 2025	Messaged UNL validators on Mattermost to recommend voting No for PermissionDelegation amendment; additional UNL validators have since applied vetoes to block the amendment.
Resolution Completed	September 29, 2025	The vulnerability has been fixed and made available in an updated amendment: PermissionDelegationV1_1.
Report Published	January 10, 2025	Blog published with details of new feature amendment.