Scoreflection
Security

Security advisories

Last updated: 5 September 2026

When we fix a security vulnerability in Scoreflection, we describe it here. This is the public record the product security page promises and that Annex I Part II (4) of the EU Cyber Resilience Act requires of us.

There are no advisories yet

Nothing has been published on this page because nothing has yet needed publishing. We would rather say that plainly than leave you wondering whether the list is empty or simply missing.

An empty list is not a claim that Scoreflection has no vulnerabilities. It means that no vulnerability has so far reached the point at which we publish: fixed, shipped, and installed by enough people that describing it helps more than it helps an attacker. If you have found something, please tell us — that is how this page gets its first entry.

When an advisory appears

We publish once a fix is available and users have had a fair chance to install it. Those are two different moments: a fix that exists in a store release nobody has downloaded yet is a description of how to attack the installed base. So the order is always: fix, ship, wait, then describe.

Waiting is not indefinite. If a vulnerability is already being exploited, or if a reporter has set a disclosure date, the timetable follows the 90-day disclosure window in our coordinated disclosure policy rather than our own convenience. And separately from this page, an actively exploited vulnerability is reported to the competent CSIRT and ENISA within the deadlines in Art. 14 of the Cyber Resilience Act, which are measured in hours, not months.

What each advisory will contain

Enough to let you decide whether you were affected and what to do, and no working exploit:

  • An identifier and a date — a Scoreflection advisory number, and a CVE where one has been assigned.
  • What was affected — the app, the API, the OMR worker or the forum, and which versions.
  • What the problem was — the class of flaw and what an attacker could have achieved, in plain language.
  • Whether it was exploited, as far as we can tell, and what our logs could and could not show.
  • What fixes it — the version to install, or the change we made on our side if there is nothing for you to do.
  • Who found it, with credit where the reporter wants it and without where they do not.

We will not publish proof-of-concept code, and we will not describe a vulnerability in a way that amounts to instructions while a meaningful number of installations are still unpatched.

Where else to look

Fixes ship as new versions through Google Play and the App Store, so the store release notes are the fastest signal that something changed. This page is the explanation behind them. The product security page holds the reporting address, the disclosure policy, the software inventory and what we commit to under the Cyber Resilience Act.