SQL injection affecting customer data, responsibly disclosed
International company (responsibly anonymized)
OffSeq founder Nils Putniņš identified a SQL injection vulnerability on the website of an international company that could have exposed customer data, and reported it through CERT.LV, Latvia's national CERT. The issue was handled under responsible-disclosure principles and remediated promptly.
High 2023 3 min read
§ 01. Overview
A SQL injection vulnerability was identified on a public-facing website belonging to an international company. Through the flaw it was potentially possible to gain unauthorized access to the company's customer data. The finding was reported to CERT.LV, the national Cyber Incident Response Institution of the Republic of Latvia, which coordinated handling with the affected organization.
The report was made by OffSeq founder Nils Putniņš in cooperation with the Digital Security Alliance. The affected organization is deliberately not named: the purpose of this page is to document the disclosure process and the class of issue, not to identify the target. Only publicly verifiable facts are stated here — no CVE or official severity rating was assigned, and exact dates and internal technical specifics are not disclosed.
§ 02. How it works
SQL injection (CWE-89) occurs when an application builds database queries by concatenating untrusted input directly into SQL statements instead of using parameterised queries. An attacker who controls part of that input can break out of the intended data context and alter the structure of the query itself — adding conditions, unions, or subqueries that the developer never intended to run.
On a customer-facing web application, this class of flaw typically lets an attacker read data that the query was never meant to return. Because the injected SQL executes with the application's own database privileges, the boundary that normally separates one user's records from another's can collapse, allowing enumeration or extraction of records belonging to other customers. The standard, well-understood remediation is parameterised queries (prepared statements) combined with least-privilege database accounts and strict input validation.
In this case the public account is deliberately general: the vulnerability was an exploitable SQL injection point on the company's website through which customer data could potentially be reached. The precise injection vector, database, and payloads are not disclosed, consistent with responsible-disclosure practice and to avoid providing a roadmap against a since-fixed system.
§ 03. Impact
The concrete risk was unauthorized access to customer data held by the affected international company. Depending on what such a dataset contains, exposure of customer records can carry data-protection consequences under the GDPR and reputational and regulatory cost for the operator.
Critically, the vulnerability was found and reported before any evidence of malicious exploitation. Under responsible-disclosure principles, the finder proved the existence of the flaw without accessing or exfiltrating third-party data beyond what was necessary to demonstrate it, and did not disclose it publicly ahead of a fix.
§ 04. Disclosure and outcome
Rather than being reported directly and unilaterally to the vendor, the finding was routed through CERT.LV, Latvia's national CERT, which operates under the Ministry of Defence and the National Cyber Security Law and coordinates incident and vulnerability handling with other CSIRTs and affected parties. This national-coordinator model provides a trusted, authoritative channel to reach an organization and see a fix through to completion.
Following the basic principles of responsible disclosure, the affected organization was informed and the threat was eliminated promptly. CERT.LV has publicly acknowledged Nils Putniņš's contributions to the security of Latvia's internet space.