Unauthenticated Payment Status Manipulation in Sipay's WooCommerce module (CVE-2026-85632)

An attacker can manipulate unauthenticated payment-status messages in the affected Sipay WooCommerce module. Remediate the integration so order fulfillment depends on authenticated and integrity-checked payment confirmation.

Public CVE record · Source and API bundle

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.

Implement the remediation

The commands are operator examples for the recorded scope. Compare fixture routes and software selectors with the intended deployment before use. See deployment prerequisites.

1. Prepare the target. Verify the loaded product and version against the advisory. Use a compatible Eden HTTP interlay and an authenticated operator with Configure permission. Open the deployment example and API instructions. The bundle identifies module gabriel_sipay_v1 version 1.0.0 and the SDK revision in patch.toml. Run the policy extraction from the adapter directory.
2. Apply the declarative policy. Scope the policy to /wp-json/wc and descendants (all methods, deny). Set INTERLAY to the target interlay UUID in the authenticated Eden CLI. Run an authenticated GET /api/v1/interlays/{interlay} with X-Eden-Verbose: true. Save its complete current settings object as current-settings.json and retain the prior remediation declaration for recovery. Set IDEMPOTENCY_KEY to a fresh key for this intended mutation.

jq -e '.tier1' deployment.json > remediation.json
jq -e --slurpfile policy remediation.json \
  '.remediation = $policy[0] | {settings: .}' current-settings.json \
  > interlay-update.json
eden api request PATCH "/api/v1/interlays/$INTERLAY" \
  --header "Idempotency-Key:$IDEMPOTENCY_KEY" \
  --body-file interlay-update.json --content-type application/json --confirm

3. Verify the serving policy. Read back the interlay.

eden api request GET "/api/v1/interlays/$INTERLAY" \
  --header 'X-Eden-Verbose:true'

Check that remediation_status.state is ready and both desired and effective SHA-256 values match the intended declaration. Replay the benign and marked requests in the recorded comparison on an isolated target. Check the recorded response and backend outcome for each probe. Use the request and expected-status table in the linked API example alongside the observed comparison. 4. Restore the previous policy. Coordinate the change with any other operator updating this interlay. Read current settings again and merge the saved remediation field into them. If the prior settings had no remediation field, omit it in the replacement. Send the same PATCH with a fresh idempotency key, then read back the intended state. Repeat the verification probes. Keep the affected route isolated if restoring the prior settings reopens exposure.

Native module gabriel_sipay_v1

1. Prepare the archive. Use the version 1.0.0 bundle for source, target, and build profile. Configure independent host approval for the installed Eden release. Use the authenticated principals required by the native authority contract. Set PATCH_ARCHIVE to the exact schema-2 package and PACKAGE_SHA256 to its expected archive digest. Verify and import it using the same target interlay.

printf '%s  %s\n' "$PACKAGE_SHA256" "$PATCH_ARCHIVE" | sha256sum --check &&
  eden api request PUT "/api/v1/interlays/$INTERLAY/patch-packages/$PACKAGE_SHA256" \
    --body-file "$PATCH_ARCHIVE" \
    --content-type application/vnd.eden.patch-package.v2+tar --confirm

2. Approve and activate. Enroll the publisher key, attest host software inventory, and inspect the configuration returned by import. Obtain independent host approval. Sign the typed statement with the matching SDK. Send the admit action followed by activate for the prepared operation. Use the applicable typed payload for each action in authority-action.json.

eden api request POST "/api/v1/interlays/$INTERLAY/native-authority" \
  --body-file authority-action.json --content-type application/json --confirm

3. Verify the operation. Read the receipt through the same endpoint. Confirm serving_now and the full expected shard acknowledgment. Repeat the report’s benign and marked probes and check the backend observations.
4. Revoke or restore. Send revoke with the exact operation UUID. Mandatory protection can refuse traffic until a compatible operation is approved and activated. Verify the restored receipt and repeat the probes.

Vendor update. Use the advisory to select the fixed release for the installed branch. Reported fixed releases include 26.9.1. Follow the vendor’s update instructions and confirm the version actually loaded by the service.

Measured comparison (fixtures10, run 2026-11-11)

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:

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