I don't write the code. I direct the agents that do.

Concrete CMS lets a user change a calendar event through an edit dialog. In versions 8.3.0 through 9.5.2, that dialog decided whether to allow the change by checking the calendar ID sent in the request, not the calendar that actually owns the event. So a user with the "Add Event" permission on one calendar could open events on calendars they had no access to, read them, and overwrite them. They could also delete an event's original local occurrence.

There was a limit. Publishing the changed version to the live calendar, which demotes the previously approved version, also needed approval rights for calendar events or a workflow that approves changes automatically.

I reported it to the Concrete CMS security team. They rated it 5.9 under CVSS 4.0, and the fix shipped in 9.5.3. The CVE record has the full description.

In Concrete CMS 9.5.0 and below, a backend component named in the CVE title as Backend\SummaryTemplate returned page metadata to visitors who were not logged in. It did this for every page with a summary template configured, including pages that were private, still in draft, or restricted.

For each of those pages, an anonymous visitor could confirm that the page existed and read its title, path, description and author. The record lists exactly those four fields, so this was a metadata leak, but it covered every page that had a summary template, whatever its permissions said.

I reported it to the Concrete CMS security team. They rated it 6.3 under CVSS 4.0: reachable over the network, with no login and no user interaction, and a low confidentiality impact. The fix shipped in 9.5.1, and the CVE record names me as the reporter.

The Concrete CMS REST API lists groups at GET /ccm/api/1.0/groups. In versions 9.2.0 through 9.5.2, the method behind that endpoint, listGroups() in Groups.php, registered a permission checker callback that returned true no matter what. The view permissions on individual groups never applied to the list.

Any authenticated user whose API token carried the groups:read scope could call the endpoint and get back every group on the site, including groups they had no permission to view. The CVE record describes what that exposes as the organization's group structure, roles, and access hierarchy.

I reported it to the Concrete CMS security team. They rated it 6.0 under CVSS 4.0, with a high confidentiality impact and a low privilege requirement, and the fix shipped in 9.5.3.

MariaDB replicas can receive compressed query events from their primary. To uncompress one, the replica reads a 32-bit length from the event header, works with it as a 64-bit value, and then casts the result back to 32 bits to decide where the data goes. Small results go into a fixed 4 KB buffer on the stack. Larger ones get a heap allocation.

If the length in the header is close to the 32-bit maximum, the cast wraps it around to a small number. The replica then picks the stack buffer for data far larger than 4 KB, and its IO thread crashes.

A normal primary cannot produce an event like that, so this needs a malicious or compromised primary, or a tampered replication stream. The ticket includes a test that reproduces the crash on a debug build. MariaDB fixed it in 10.11.19, 11.4.13, 11.8.9 and 12.3.3, released August 24, 2026, and in 13.0.2.