Concrete5 ProEvent SQL Injection to RCE

Summary

Concrete5 ProEvent exposed a SQL injection in calendar routes that passed unsanitized request parameters into the eventIs() query builder. The issue could be chained from unauthenticated route access to database modification, administrator login, file upload changes, and remote code execution on a standard LAMP deployment.

Affected Surface

  • Product: Concrete5 add-on ecosystem
  • Component: ProEvent
  • Affected version observed: ProEvent 2.8.1
  • Platform observed: Concrete5 5.7.5.6 on Ubuntu 14.04 LAMP
  • Vulnerability classes: SQL injection, authentication bypass by credential overwrite, insecure upload configuration leading to RCE

Impact

An attacker could execute SQL statements through ProEvent calendar routes. In the tested environment this allowed modifying the administrator password hash, logging in as admin, permitting PHP uploads, uploading a PHP payload, and executing commands as the web server user.

This was a critical chain because a single SQL injection crossed from data-layer compromise to application administrator access and server-side code execution.

Root Cause

The eventIs() function built SQL by concatenating variables directly into a SELECT statement. Calendar route handlers passed request-controlled values such as category and section parameters into this function without sanitization or prepared statements.

The route was reachable even when the corresponding calendar view was not actively displayed on a page because ProEvent registered the route during installation.

Evidence

Testing confirmed that a crafted request to the ProEvent calendar_small route altered the generated SQL query. Database logs showed injected statements executing against the Concrete5 database.

After confirming write capability, the proof of concept updated the administrator password hash, authenticated as admin, changed allowed upload types to include PHP, uploaded a PHP file, and reached the uploaded file directly to obtain command execution.

Remediation

  • Replace string-concatenated SQL with prepared statements and parameter binding.
  • Validate route parameters before they reach query-building code.
  • Disable or protect installed add-on routes that are not actively needed.
  • Prevent executable server-side file types from being enabled through the web UI.
  • Treat marketplace add-on updates as security-sensitive and notify installed users when critical fixes ship.

Timeline

  • 2016-02-01: Plugin developer notified
  • 2016-04-11: Public forum discussion started after the issue remained present
  • 2016-04-13: Developer applied the supplied patch
  • 2016-04-14: Public report published

Notes

The finding highlighted a process gap as much as a code flaw: add-on vulnerability reports need a clear intake path, a marketplace response plan, and user notification when critical add-on fixes are released.

Supporting Links