CVE-2026-28443 is an SQL injection in OpenReplay, a self-hosted session replay suite. The cards search endpoint builds its ORDER BY clause from the sort.field parameter without validation. NVD scores it 9.8 and says it is patched in 1.20.0. Update your deployment.
What's affected
NVD's description says versions prior to 1.20.0 are affected and that 1.20.0 patches it. The GitHub advisory GHSA-q6gf-3qg3-pww5 is less tidy: its affected field reads 1.0.0 and below, its patched field says none, and its remediation text says the fix is in the chalice, api and spot services in versions after v1.20, pulled with the update command. Use NVD's version as the target and confirm in the OpenReplay release notes.
The affected endpoint is the cards search route, the POST cards search route under the project path. The advisory shows that a schema field for the sort column accepts any string, and that the value is placed into the ORDER BY clause of a query through string formatting. Parameter placeholders protect values, but the sort column was inserted before they were applied.
The maintainers rate it Moderate, while NVD scores it 9.8 with no privileges required. The weakness is CWE-89 (SQL Injection).
How to check if you're exposed
Find your OpenReplay version and which services you run. OpenReplay is self-hosted, so you control the version.
If you installed with the project's command line tool, the update command from the advisory is openreplay -u. After updating, confirm the version of the chalice, api and spot services is newer than 1.20.
Then check exposure. Is the API reachable from the internet, or only from your network? Session replay platforms often hold recordings of real user sessions, so treat the data as sensitive.
What to do now
- Update OpenReplay to 1.20.0 or later, using the update command in the advisory, and confirm the service versions.
- Restrict access to the API and dashboard to your network or a VPN if you can.
- Review database logs and access logs for unexpected requests to the cards search endpoint with unusual sort values.
- Review which database account the API uses and reduce its rights to what OpenReplay needs.
- Check that other endpoints validate sort and order fields with allow lists, since the advisory notes other endpoints did this properly.
Why it matters
ORDER BY clauses are a classic blind spot. Developers parameterise values, then build the sort column by string formatting, since a column name cannot be passed as a value. If the column name comes from a request, the request controls part of the SQL.
The advisory points at the contrast inside the same codebase. Other endpoints validate the direction of the sort with an enumeration type. This one used a plain string for both the field and the order. The fix pattern is to accept only names from a fixed list of allowed columns and map them to SQL in code.
Session replay data is a rich target. It records how users interact with an application, and depending on masking settings can include sensitive pages. A database injection on that platform raises more than a technical question.
The record does not flag exploitation in the wild, and the CVE is not in CISA's Known Exploited Vulnerabilities catalog. Static analysis catches this class well, since a user controlled value flowing into an f-string query is exactly the pattern it looks for.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why are there two different version statements?
NVD says prior to 1.20.0. The advisory's fields are inconsistent, listing 1.0.0 and below as affected and none as patched while the text says versions after v1.20 are fixed. Plan to 1.20.0 or later and verify in release notes.
What is the right way to handle a sort field?
Accept only names from an allow list of columns and map them to SQL in code, never pass the request value into the query text.
Sources
Last reviewed: 19 October 2026.
