AGR-2026-107 — Automatic client ignores payment preference ordering
Last observed by the head-to-head audit at 2026-09-14T09:17:13.387847Z.
Audited heads
| Target |
Repository |
Commit |
Conformance |
Semantic review |
typescript |
wevm/mppx |
3c14a65a7ea5 |
Complete |
Reference |
ruby |
stripe/mpp-rb |
3b9e2923c67b |
Complete |
Complete |
go |
tempoxyz/mpp-go |
9fcf9a47c61b |
Complete |
Complete |
java |
stripe/mpp-java |
ca57f0998545 |
Complete |
Complete |
python |
tempoxyz/pympp |
7988d1cda5c4 |
Complete |
Complete |
rust |
tempoxyz/mpp-rs |
d859a13d74ef |
Complete |
Complete |
Finding
- Fingerprint:
semantic:negotiation/honor-client-payment-preferences
- Source: semantic
- Affected SDKs:
ruby
- Clean SDKs: none
- Not reported by semantic review:
go, java, python, rust
- Canonical reference:
draft-ietf-httpauth-payment §7.1 (Challenge Negotiation with Accept-Payment)
- Severity: medium
- Confidence: high
Evidence
| SDK |
Canonical evidence |
SDK evidence |
Suggested test |
ruby |
selectChallengeCandidates — Matches challenges by method and intent, excludes non-matches and q=0 offers, then orders candidates by protocol rank, preference quality, and server order. |
find_matching_challenge — Scans WWW-Authenticate values in wire order and immediately returns the first challenge whose method name exists in the method map, without consulting Accept-Payment preferences. |
Configure two supported methods with the first server challenge assigned q=0 and the second q=1 in Accept-Payment; assert the automatic client advertises the preferences and creates a credential only for the second challenge. |
ruby: The canonical client advertises its supported payment preferences and selects compatible challenges by protocol rank, quality, specificity, and server order. The target sends no derived Accept-Payment header and returns the first challenge whose method name is registered. Consequently, it can pay a lower-priority offer, select an offer explicitly assigned q=0 by the caller, or fail to influence a server that tailors its challenge set from Accept-Payment.
Available /ag commands
Post a command as a new comment. Only configured maintainers can run these commands.
| Command |
What it does |
/ag status |
Reports the current state of linked remediation pull requests. |
/ag fix is unavailable for ruby because the affected SDK is configured for notification-only automation.
AGR-2026-107 — Automatic client ignores payment preference ordering
Last observed by the head-to-head audit at
2026-09-14T09:17:13.387847Z.Audited heads
typescriptwevm/mppx3c14a65a7ea5rubystripe/mpp-rb3b9e2923c67bgotempoxyz/mpp-go9fcf9a47c61bjavastripe/mpp-javaca57f0998545pythontempoxyz/pympp7988d1cda5c4rusttempoxyz/mpp-rsd859a13d74efFinding
semantic:negotiation/honor-client-payment-preferencesrubygo,java,python,rustdraft-ietf-httpauth-payment §7.1 (Challenge Negotiation with Accept-Payment)Evidence
rubyruby: The canonical client advertises its supported payment preferences and selects compatible challenges by protocol rank, quality, specificity, and server order. The target sends no derived Accept-Payment header and returns the first challenge whose method name is registered. Consequently, it can pay a lower-priority offer, select an offer explicitly assigned q=0 by the caller, or fail to influence a server that tailors its challenge set from Accept-Payment.
Available
/agcommandsPost a command as a new comment. Only configured maintainers can run these commands.
/ag status