CVE-2026-85632Discovered Published
Unauthenticated Payment Status Manipulation in Sipay's WooCommerce module
View patch bundle on GitHubFull published report
The reviewed summary below describes the scope of the fixture testing.
Unauthenticated Payment Status Manipulation in Sipay's WooCommerce module (CVE-2026-85632)
cve.now entry. Product: Sipay Electronic
Money and Payment Services WooCommerce virtual POS module (lab:
gabriel-sipay-app).
Eden terminates the HTTP connection to the affected product, evaluates a declarative policy and — in tier 2 — a separately compiled native Rust module under signed module authority, before any byte reaches the application. It does not patch the affected component; the vendor's fixed release remains the durable repair.
Status: Remediated (tier 1 + tier 2), live-proven 2026-11-11T17:09:25Z on the
installed eden-product-release:1.103.0 lab container.
The vulnerability
Sipay's WooCommerce module exposes a payment-status endpoint that an
unauthenticated caller can drive to flip an order to completed. The fixture
(make_sipay, port 18319) reproduces the delivery shape: a status-flip body
("status": "completed") without an Authorization header records a
payment-changed mark; the same body with a merchant bearer passes without
effect.
The Eden patch
Tier 1 — declarative policy (blunt, fail-closed): deny every request under
/wp-json/wc, merchant-server status updates included — false positives
measured below.
Tier 2 — native Rust module gabriel_sipay_v1 (surgical): refuses
status-flip bodies that arrive without an Authorization header;
authenticated merchant-server updates pass unchanged.
Measured comparison (fixtures10, run 2026-11-11)
| Probe | Baseline | Tier 1 | Tier 2 (module) | Backend effect |
|---|---|---|---|---|
benign authorized status update (Authorization: Bearer merchant-key) | 200 | 403 (false positive) | 200 | none |
| attack: unauthenticated status flip | 200 (payment_changed recorded) | 403 | 403 | blocked at tier 2 |
Performance trace (Eden telemetry, live 2026-11-11)
Measured with Eden's built-in request telemetry (gateway.request.baseline
spans, read back through /api/v1/analytics/telemetry?signal=traces), not
client wall-clock. Latency Eden introduces per remediation arm for this case:
| Arm | n | mean | p50 | p95 | min–max |
|---|---|---|---|---|---|
| Tier 1 — declarative policy, blocked request (403) | 15 | 32 µs | 24 µs | 59 µs | 14 µs–59 µs |
| Tier 2 — native module, benign passes through (200) | 21 | 391 µs | 364 µs | 484 µs | 338 µs–668 µs |
| Tier 2 — native module, attack refused (403) | 14 | 148 µs | 141 µs | 234 µs | 112 µs–234 µs |
Eden-added latency for the tier-2 remediation: benign requests complete in 391 µs mean (p50 364 µs, p95 484 µs) in-product, module evaluation included. Honest scope: lab fixtures on one host, fresh connection per measured request, warm requests only; module reactivated shards 2/2 with a fresh signed statement per measurement; spans carry the full authority lineage (module SHA-256, operation, publication). Not the EDEN-3640 performance qualification contract.
Tested against: eden-product-release:1.103.0-single (image sha256:809293e1f0b525ac…, build target
eden_service_single, tooling revision 81a0724a…). Raw data:
module2/telemetry-ab/sipay-telemetry.json and module2/tier1-ab/sipay-tier1.json.
Authority lifecycle and negatives
Import 201, activation: explicit_required; publisher enroll_key, host
inventory + approve, reader inspect refused 403; tampered-statement admit
400; invalid-signature admit 403; admit prepared (not serving), activate
→ receipt serving_now, applied shards 2/2. Revoke → the identical attack
gets 503 (fail-closed); re-approve + re-activate → 403 again. All recorded
in the evidence JSON.
Honest scope
The module cannot validate the bearer token itself (no store access at the
gateway), so it enforces presence-of-authorization only — a stolen valid token
still passes, and other status values are unguarded. First live attempt hit the
trailing-slash policy rejection (E04FF) and a native-conditions exact-path
mismatch; both fixed, case re-run clean. Module binary SHA-256 c77b6260…,
source modules/gabriel_sipay_v1.rs.
Cost record
Run window 17:09:25Z → 17:09:34Z (per-CVE ledger, marginal session cost).
Evidence appendix
- Fixture:
gabriel-2026-11-11/fixtures10.py(make_sipay, port 18319) - Evidence:
gabriel-2026-11-11/module2/evidence/sipay-module.json - Module source:
docs/case-studies/modules/gabriel_sipay_v1.rs
The vulnerability
Sipay's WooCommerce module exposes a payment-status endpoint that an
unauthenticated caller can drive to flip an order to completed. The fixture
(make_sipay, port 18319) reproduces the delivery shape: a status-flip body
("status": "completed") without an Authorization header records a
payment-changed mark; the same body with a merchant bearer passes without
effect.
The Eden patch
Tier 1 — declarative policy (blunt, fail-closed): deny every request under
/wp-json/wc, merchant-server status updates included — false positives
measured below.
Tier 2 — native Rust module gabriel_sipay_v1 (surgical): refuses
status-flip bodies that arrive without an Authorization header;
authenticated merchant-server updates pass unchanged.
Measured comparison (fixtures10, run 2026-11-11)
| Probe | Baseline | Tier 1 | Tier 2 (module) | Backend effect |
|---|---|---|---|---|
benign authorized status update (Authorization: Bearer merchant-key) | 200 | 403 (false positive) | 200 | none |
| attack: unauthenticated status flip | 200 (payment_changed recorded) | 403 | 403 | blocked at tier 2 |
Performance trace (Eden telemetry, live 2026-11-11)
Measured with Eden's built-in request telemetry (gateway.request.baseline
spans, read back through /api/v1/analytics/telemetry?signal=traces), not
client wall-clock. Latency Eden introduces per remediation arm for this case:
| Arm | n | mean | p50 | p95 | min–max |
|---|---|---|---|---|---|
| Tier 1 — declarative policy, blocked request (403) | 15 | 32 µs | 24 µs | 59 µs | 14 µs–59 µs |
| Tier 2 — native module, benign passes through (200) | 21 | 391 µs | 364 µs | 484 µs | 338 µs–668 µs |
| Tier 2 — native module, attack refused (403) | 14 | 148 µs | 141 µs | 234 µs | 112 µs–234 µs |
Authority lifecycle and negatives
Import 201, activation: explicit_required; publisher enroll_key, host
inventory + approve, reader inspect refused 403; tampered-statement admit
400; invalid-signature admit 403; admit prepared (not serving), activate
→ receipt serving_now, applied shards 2/2. Revoke → the identical attack
gets 503 (fail-closed); re-approve + re-activate → 403 again. All recorded
in the evidence JSON.
Honest scope
The module cannot validate the bearer token itself (no store access at the
gateway), so it enforces presence-of-authorization only — a stolen valid token
still passes, and other status values are unguarded. First live attempt hit the
trailing-slash policy rejection (E04FF) and a native-conditions exact-path
mismatch; both fixed, case re-run clean. Module binary SHA-256 c77b6260…,
source modules/gabriel_sipay_v1.rs.
Cost record
Run window 17:09:25Z → 17:09:34Z (per-CVE ledger, marginal session cost).