GIVE YOUR AGENT THE EVIDENCE

Set up in your agent.

One prompt to get started. Paste it into your coding agent to connect cve.new through MCP and bring vulnerability context into your workflow.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

GIVE YOUR AGENT THE EVIDENCE

Investigate in your agent.

Turn this advisory into a focused investigation. Ask your agent to check your project’s versions, explain the evidence, and suggest a compatible fix.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

Check your stack
GHSA-3vxg-x5f8-f5qflow1.7

Craft Commerce has an unauthenticated information disclosure that can leak some customer order data on anonymous payments

Impact

PaymentsController::actionPay discloses some order data to unauthenticated users when an order number is provided and the email check fails during an anonymous payment.

Source excerpt · OSV

Affected packages

Start with the recorded fix for your release branch. Check your installed version and test compatibility before upgrading. Fixing this advisory does not rule out other vulnerabilities in the release.

Affected rangeRecorded fix
From 5.0.0 before 5.6.0Ecosystem versions5.6.0
From 4.0.0 before 4.11.0Ecosystem versions4.11.0

Version evidence: OSV · GHSA-3vxg-x5f8-f5qf

View original version evidence (159 explicit versions)

Original source description

Summary

PaymentsController::actionPay discloses some order data to unauthenticated users when an order number is provided and the email check fails during an anonymous payment.

The JSON error response includes the serialized order object (order), which contains some sensitive fields such as customer email, shipping address, and billing address.

Details

I manually audited frontend payment flows and found that actionPay() retrieves orders by number before authorization is fully enforced.

Code path:

  1. Load order by number.
  2. Evaluate whether payment is authorized for completed orders (number + matching email).
  3. If unauthorized, return failure.
  4. Failure response still includes cartArray($order), which serializes sensitive order data.

Why is this a vulnerability?

  • Authorization logic says the requester is not allowed to pay for a completed order without an email.
  • But the response still returns the same completed order’s contents.

Impact

Type: Information Disclosure / Broken Access Control

Who is impacted:

  • Any Commerce deployment where completed order numbers can be obtained or leaked.

References