A missing security check on a GET collection endpoint let anyone with a basic CoopCycle account pull the full address book of every store in a shared instance, exposing names, street addresses and postcodes of countless customers. The flaw was patched within two days, and users are urged to upgrade to the latest released version.
How the leak happened
CoopCycle – an open-source logistics platform used by food-delivery cooperatives – defines its API with the PHP framework API Platform. In that framework each operation (POST, GET, etc.) must be paired with a security expression; if the expression is omitted the framework runs the code without any authorization check.
The developers protected the POST request that creates or updates a store’s address list with the standard expression is_granted('edit', object). That works because the request targets a single store entity, giving the framework a concrete “object” to evaluate.
The GET request that reads the same resource targets a collection: /api/stores/{id}/addresses. A collection has no single object, so the same is_granted('edit', object) expression cannot be applied. Because the developers left the security line out, the framework served the address data to any authenticated user, regardless of tenancy.
On a shared CoopCycle instance a malicious user could simply iterate through store IDs, issue GET requests to the endpoint, and scrape the home addresses of every customer stored in the system. No extra privileges were required beyond a normal account.
Why the bug survived
The problem was not a simple oversight. API Platform’s declarative security model lacks a straightforward way to express “the user must belong to the same tenant as each object in the collection.” The missing line of code sat exactly where the framework made authorization cumbersome.
Compounding the issue, the project’s test suite actually asserted that the GET response containing all addresses was the expected behavior. In other words, the automated tests passed because the fixtures used in testing allowed cross-tenant access, effectively masking the vulnerability. A green test suite, in this case, gave a false sense of security.
Who wins and who loses
- Customers: Their personally identifiable information (PII) – full names and home addresses – were exposed to anyone on the platform. Even though the data was not publicly posted, the breach compromised privacy across multiple cooperatives.
- Cooperatives using CoopCycle: Trust in the platform’s ability to safeguard tenant data was shaken. Any cooperative that had not yet upgraded faced the risk of continued exposure.
- The CoopCycle maintainers: Their quick response – a patch within two days and added regression tests – limited the window of exploitation and demonstrated responsible open-source stewardship. The incident, however, highlights the need for tighter security review processes, especially around framework-driven defaults.
What developers and auditors should look for
- Operation asymmetry: If a POST (or any mutating operation) on a path is guarded but the corresponding GET is open, the discrepancy is a red flag. The POST reveals the developers’ intent to protect the resource.
- Collection endpoints: Anything that returns a list rather than a single item often falls outside the usual security patterns. Verify that authorization checks are explicitly added for bulk reads.
- Test suite realism: Ensure fixtures reflect real tenancy boundaries. A passing test that validates cross-tenant data leakage is a warning sign, not a green light.
The fix and next steps
After the vulnerability was reported, the CoopCycle core team added the missing security expression to the GET collection operation and introduced regression tests that enforce tenant isolation for both single-item and collection endpoints. The patch shipped in a subsequent version of the software.
Users of CoopCycle should:
- Verify they are running a recent version of the software.
- Review any custom extensions or plugins that might introduce similar collection-level gaps.
- Re-run security scans with a focus on read/write asymmetries across all API routes.
Takeaway
सुरक्षा डिक्लेरेटिव्ह (declarative) बनवणारे फ्रेमवर्क्स धोकादायक त्रुटी लपवू शकतात, जेव्हा डेव्हलपर्स अशा पॅटर्नवर अवलंबून असतात जे केवळ सिंगल ऑब्जेक्ट्ससाठी कार्य करतात. एक साधी तपासणी—एखाद्या एंडपॉइंटची 'रीड साइड' (read side) आणि 'राईट साइड' (write side) मध्ये समान गार्ड (guard) आहे का?—अशा क्रॉस-टेनंट लीक्सचा (cross-tenant leaks) एक प्रकार उघड करू शकते, जो अन्यथा 'ग्रीन टेस्ट सूट्स'च्या (green test suites) मागे लपलेला राहिला असता.