CVE-2026-8827
SQL Injection in AddressRepository Extension
Publication date: 2026-05-19
Last updated on: 2026-05-19
Assigner: TYPO3
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| typo3 | address_list | 10.0.0 |
| typo3 | address_list | to 9.1.0 (inc) |
| typo3 | address_list | to 8.1.2 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-89 | The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
The vulnerability exists in the TYPO3 extension "Address List" (tt_address) in the AddressRepository::getSqlQuery() method. This method constructs a database query without properly sanitizing user input, which can lead to SQL Injection.
Although this method is not used within the extension itself, custom extensions that call this method with untrusted input could expose the site to SQL injection attacks.
How can this vulnerability impact me? :
If a custom extension calls the vulnerable method with untrusted input, an attacker could exploit this to perform SQL Injection attacks.
- This could allow attackers to manipulate database queries.
- Potential impacts include unauthorized data access, data modification, or data deletion.
- It could compromise the integrity and confidentiality of the database.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability arises from the AddressRepository::getSqlQuery() method being called with untrusted input in custom extensions. Since the method is not invoked in the default extension, detection involves identifying if any custom extensions or code call this method with user input.
To detect potential exploitation or presence of this vulnerability, you should:
- Review your TYPO3 custom extensions or code for calls to AddressRepository::getSqlQuery() that pass user input without sanitization.
- Monitor database logs for unusual or unexpected SQL queries that could indicate SQL injection attempts.
- Use web application firewall (WAF) logs or intrusion detection systems (IDS) to detect SQL injection patterns targeting your TYPO3 installation.
Specific commands depend on your environment, but examples include:
- Using grep to search for calls in your codebase: grep -r 'getSqlQuery' /path/to/typo3/extensions/
- Checking database logs for suspicious queries, e.g., tail -f /var/log/mysql/mysql.log | grep -i 'select' or other relevant patterns.
What immediate steps should I take to mitigate this vulnerability?
The primary immediate mitigation step is to update the TYPO3 Address List extension to a fixed version.
- Upgrade the Address List extension to version 10.0.1, 9.1.1, or 8.1.2 or later, as these versions address the SQL injection vulnerability.
- Audit any custom extensions or code that call AddressRepository::getSqlQuery() to ensure they properly sanitize user input before passing it to this method.
- Follow TYPO3 Security Guide recommendations to harden your TYPO3 installation.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows for SQL Injection if custom extensions call the vulnerable method with untrusted input, potentially leading to unauthorized access or manipulation of sensitive data stored in the database.
Such unauthorized access or data breaches could impact compliance with data protection regulations like GDPR or HIPAA, which require safeguarding personal and sensitive information against unauthorized access.
However, the vulnerability itself is not exploitable in a default installation, and the risk arises only when custom extensions improperly use the vulnerable method.