Community Store, an open-source e-commerce add-on for Concrete CMS, stored customer-supplied order fields without sanitizing them and rendered them without HTML escaping across four admin-facing views. Any unauthenticated visitor could place an order with a script payload in a field like billing first name, and the payload would execute inside a store manager's authenticated dashboard session the next time they opened that order, enough to create a rogue administrator account or exfiltrate session data.

What's Affected

Every order carries customer-supplied fields: billing/shipping first name, last name, email, and phone. Those fields are stored as-is and rendered back out in four places a store manager routinely looks at:

• the admin order view (single_pages/dashboard/store/orders.php)
• the printable order slip (elements/order_slip.php)
• the sales report (single_pages/dashboard/store/reports/*.php)
• the customer-facing checkout confirmation page (single_pages/checkout/complete.php)

Crucially, placing an order requires no account. Community Store's guest checkout setting defaults to always, set that way by the package's own installer on every fresh install, not something a store operator has to opt into. So this isn't a bug that needs a misconfigured store; it's exploitable against a default, out-of-the-box installation, no credentials required.

Mitigation

Update Community Store to 2.7.8 or later. The fix adds proper output escaping to all four affected render locations. There's no config workaround short of upgrading, since the vulnerable behavior is the escaping itself, not a toggle.

Technical Details

None of the four render locations escaped the customer-controlled fields. A representative line from the admin order view:

No h() call, Concrete's standard output-escaping helper, anywhere near it, even though the same file used h() correctly a few lines away for other values. Input validation was no better: the only check applied to these fields was a length limit (1-255 characters), nothing that stripped or rejected HTML.

A <script> payload under 255 characters in the billing first name field passes validation untouched, gets stored, and later renders unescaped wherever an admin looks at the order.

The guest checkout default is set directly in the installer:

The checkout controller only forces a login when that setting is off (or option without a guest flag), and with the installed default, that branch never triggers.

Proof of Concept

Tested against Community Store v2.7.7 on Concrete CMS 9.5.2 (self-hosted Docker lab, PHP 8.3). Payload submitted as an ordinary guest checkout, no authentication of any kind:

1. Attacker submits a normal-looking checkout with the payload above. No account, no session, no cookies.
2. A store manager opens Dashboard > Store > Orders and views the order (the payload fires equally from the order slip, sales report, or the customer's own confirmation email; any of the four unescaped render paths work).
3. The script executes with the store manager's authenticated session and CSRF token. To confirm real impact rather than just an alert box, I hosted the payload myself, as an outside attacker would, and used it to programmatically submit the "add administrator" form from inside that session, turning a single malicious order into a full admin account takeover.

Disclosure Timeline

• Reported to the maintainer via a private GitHub security advisory
• Fix shipped by Ryan Hewitt as commit 2a802d6, adding h() escaping to all four affected render locations
• Fix included in the v2.7.8 release
• CVE-2026-93659 published via VulnCheck as CNA, credited to me as finder

Takeaways

• Output escaping has to be applied consistently across every render path for a given value, not just the obvious ones. This bug shipped for years because three of the four render locations were apparently never revisited after the fourth was handled correctly.
• "Requires an account" isn't a safe assumption to build a threat model on for an add-on with configurable guest access. Check the actual shipped default, not the theoretical safe configuration.
• Marketplace/community add-ons for popular CMS platforms are a good place to start bug hunting: real install base, genuinely less audited than core.

References

• CVE-2026-93659
• Fix commit 2a802d6
• v2.7.8 release notes
• Community Store repository