Concrete5 ProBlog CSRF to Stored XSS

Summary

Concrete5 ProBlog accepted authenticated blog-create POST requests without validating an anti-CSRF token. The same workflow also trusted the supplied parent page ID, allowing a forged request to place attacker-controlled content outside the expected blog tree.

Affected Surface

  • Product: Concrete5 add-on ecosystem
  • Component: ProBlog add-on
  • Affected version observed: ProBlog 2.6.6
  • Related component: ProEvent 2.8.5 was also fixed by the developer
  • Vulnerability classes: CSRF, stored XSS, authorization/placement validation weakness

Impact

If an authenticated Concrete5 administrator or editor visited an attacker-controlled page, the attacker could submit a hidden form that created a published blog/page entry containing malicious JavaScript.

Because the parent page ID was not constrained to the blog section, the attacker could hide the created content elsewhere in the site map, making detection harder and increasing the chance that the stored payload remained active.

Root Cause

The add-on’s create-blog endpoint did not enforce CSRF token validation and did not verify that cParentID referred to an allowed blog parent. The request trusted client-supplied state for both write authorization context and content placement.

Evidence

A forged POST to the ProBlog add endpoint could set fields such as title, body, publication state, date, page type, and parent page ID. The body field could contain a JavaScript payload, and the parent page ID could target a location outside the blog tree.

Remediation

  • Require Concrete5 CSRF token validation on all state-changing add-on routes.
  • Validate that the current user is authorized for the requested parent page.
  • Restrict ProBlog-created pages to approved parent locations.
  • Sanitize or encode user-supplied blog body content according to the intended editor trust model.
  • Log and notify administrators when unexpected content is created outside normal workflows.

Timeline

  • 2016-04-22: Reported through HackerOne and security@concrete5.org
  • 2016-04-22: Developer fixed the issue in under three hours and posted an updated version
  • 2016-05-22: Public disclosure after 30 days

Notes

The developer responded quickly and proactively fixed related issues in both ProBlog and ProEvent.

Supporting Links