SURIQ
Suprema's BioStar 2 controls who gets through the door. This week it also became a route into the domain. A high-severity flaw tracked as CVE-2026-31278 lets any account with operator-level access read the platform's stored Active Directory (AD) service-account password back in plaintext. If you run BioStar 2 with directory login enabled, the upgrade is not your first move. Rotating that account is.
What the flaw actually exposes
BioStar 2 integrates with Active Directory so staff can sign in with their directory accounts. To do that, it stores a bind account: a directory service account and its password, used to query the Lightweight Directory Access Protocol (LDAP) server. The web console masks that password behind dots, the way any settings screen should.
The application programming interface (API) behind the console does not. Researcher Abdullah Alannaz reported that a simple GET request to the /api/v2/setting/adserversetting endpoint returns the bind account name, its password, the LDAP server address, and the SSL configuration, all readable in the clear. The issue is classified as CWE-319, cleartext transmission of sensitive information. The affected products are named in the CVE record and in the researcher's public writeup.
It carries a CVSS score of 7.7. The shape of the flaw matters more than the number: an attacker needs a valid, low-privilege login to reach the endpoint, but nothing beyond that. The severity rating treats scope as changed, because the secret it hands over belongs to a different security boundary entirely. That is your directory, not the door controller.
Which versions are affected
- Affected: BioStar 2 before 2.9.12, and BioStar X before 1.0.2.
- Fixed: BioStar 2 version 2.9.12, and BioStar X version 1.0.2.
There is no report of exploitation in the wild, and the flaw is not in the CISA Known Exploited Vulnerabilities catalog at the time of writing. A researcher writeup describing the endpoint is already public, so treat the technique as known rather than theoretical.
Why patching is step two, not step one
Here is the part a plain advisory recap skips. From the moment that endpoint shipped, the bind password was readable by anyone who has ever held an operator login on that server. Upgrading to 2.9.12 stops the endpoint from handing it out again. It does nothing about the credential that already walked out the door.
That credential is rarely a low-value one. A directory bind account is often granted more read access across the domain than it strictly needs, and service-account passwords tend to sit unchanged for years because rotating them means touching every system that authenticates against them. So the realistic blast radius is domain reconnaissance and lateral movement using a legitimate account, launched from a physical-access appliance that most security teams never put inside their identity threat model.
How to tell if someone already pulled it
The endpoint is a legitimate admin API, so you cannot simply block it. You can watch it. Read your BioStar 2 web tier access logs for requests to the settings endpoint, and treat any session or source address that fetched it as one that has seen the password.
grep "/api/v2/setting/adserversetting" access.log # who pulled it, so you know whose view of the secret is now burned grep "/api/v2/setting/adserversetting" access.log | awk '{print $1, $4}' | sort | uniq -c | sort -rn
If your BioStar 2 server sends its logs to a managed detection service, this is a one-line detection to stand up: alert on reads of that path from anything other than the handful of admin sessions that legitimately open the AD settings screen.
Rotate the credential before you patch
Work the exposure, not just the version number.
- Reset the Active Directory service account's password now, and audit what that account can actually read across the domain. If it has more rights than the BioStar 2 integration needs, trim them.
- Upgrade BioStar 2 to 2.9.12, or BioStar X to 1.0.2, to stop the endpoint from leaking again.
- Keep the BioStar 2 API off the open internet and restrict it to a management network. Physical-access consoles do not belong on a public interface.
- Turn on LDAPS so the directory traffic itself is encrypted in transit, not only the stored setting.
The pattern worth noticing
This is the same failure we keep documenting under a different logo: a secret dutifully masked in the interface while an API quietly returns it in full. We saw it when Puppet stored the passwords it was told to hide in cleartext, when SUSE Rancher kept cluster join tokens in plaintext, and in the Squid proxy credential leak. The dots on the screen are cosmetic. Assume every stored secret your platform holds is exactly as protected as its least-guarded read path, and test that read path yourself before an advisory does it for you.