Skip to main content
HDWSec
High CVE-2026-112064TYPO3-EXT-SA-2026-029

sgalinski Cookie Consent for TYPO3: SQL Injection in the Backend Consent History Module

Severity
High
CVSS score
7.1CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
CVE number(s)
CVE-2026-112064TYPO3-EXT-SA-2026-029
Vendor
sgalinski Internet Services GmbH
Product
sgalinski Cookie Consent (sg_cookie_optin) for TYPO3 CMS (backend consent history, Classes/Service/OptinHistoryService.php - searchUserHistory())
Affected version(s)
7.4.5 and below, 8.0.0 through 8.1.11
Fixed version(s)
7.4.6 and 8.1.12, released 2026-10-20
Vulnerability type
SQL Injection (CWE-89) through unvalidated sorting, grouping and index options concatenated into a raw query
Researchers
Jean-Jamil KHALIFÉ

Presentation

“sgalinski Cookie Consent” (sg_cookie_optin) is a third-party TYPO3 extension that renders the cookie consent banner of a site and records the choices visitors make. Its backend module lets editors review that consent history and display statistics, and it feeds those two views through AJAX routes that take their filtering, sorting and grouping options from the request.

HDW Sec found that the consent history query was assembled by string concatenation: only the filter conditions were bound as parameters, while the sorting, grouping and index options coming from the request went into the SQL statement unvalidated. A backend user holding the lowest-privileged editor account could therefore read arbitrary data from the database, including the password hashes of backend and frontend users.

The TYPO3 Security Team rates the issue High and the suggested CVSS 4.0 vector scores 7.1. The vulnerability needs a backend account, and it reads data without granting any write access.

Issue(s)

  • The backend AJAX endpoints searchUserPreferenceHistory() and searchUserPreferenceHistoryChart() in Classes/Backend/Ajax.php decode the params body of the request and hand it to OptinHistoryService::searchUserHistory() almost untouched: only the useIndex key is overwritten.
  • searchUserHistory() in Classes/Service/OptinHistoryService.php builds its statement by concatenation. The groupBy entries land in the GROUP BY clause, orderBy in ORDER BY and useIndex in USE INDEX, none of them validated, while only the WHERE filters are passed as bound parameters.
  • Each groupBy entry is also appended to the SELECT list, so an arbitrary sub-select is echoed verbatim in the JSON response. The read is direct and needs no blind technique.
  • The module is registered with access = 'user' and the route token of the AJAX endpoint is exposed in TYPO3.settings.ajaxUrls on every backend page, so any authenticated backend user reaches the sink regardless of their permissions.
  • Confirmed on 8.0.4 from a non-admin editor account: the response returned the be_users admin password hash, and a second payload returned the database version, the connection user and the schema name.
  • The impact stays confined to confidentiality, and the vector keeps VC:H with VI:N and VA:N. Disclosure of the administrator hash still opens the way to offline cracking and to a full administrative takeover.
  • TYPO3 classifies the flaw as CWE-89 (SQL injection). The same advisory also fixes two missing authorization issues (CWE-862), one on the history and statistics routes and one on the JSON import of the consent configuration, shipped in the same releases.
  • The fix belongs with an allowlist: validate each sorting, grouping and index value against the real column and index names plus the sort direction, or build the statement with the QueryBuilder API (orderBy(), groupBy(), addSelectLiteral() over quoteIdentifier()).
  • The score follows CVSS 4.0 because TYPO3 publishes its advisories in that version, while the rest of this database records CVSS 3.1 vectors.

References

Our R&D hunts for vulnerabilities.

Zero-day research, reverse engineering, coordinated disclosure: discover our R&D team.