CVE-2025-59379: The Login Page That Answered Questions It Shouldn't Have

Dwyer-Omega's Isensix Advanced Remote Monitoring System (ARMS) 1.5.7 leaks database contents through a blind SQL injection in the user parameter of the login form — the one door every web app is supposed to keep boring, and this one cheerfully tells the attacker about the shape of the furniture inside.

The advisory in plain English

Isensix ARMS is a cold-chain and environmental monitoring platform — think refrigerator temperatures in hospitals, clean-room humidity in labs, the long, quiet tail of IoT gear humming away in places where the SLA on "is my vaccine still good?" is measured in lives. CVE-2025-59379 (CVSS 7.5, High) targets the login page of ARMS 1.5.7 and earlier. The user field, whatever a human might be expected to type into it, is concatenated into a SQL query without adequate sanitisation, and the application's boolean reply to that query — login succeeded, login failed, or something more interesting — differs enough that an attacker can play twenty-questions with the database until it tells them who the users are and what their passwords look like.

The advisory calls this out as classic blind SQL injection: no error messages spilling rows to the screen, no UNION SELECT dumping tables in one shot, just the binary oracle of "did the page render differently?" coaxed into leaking data one bit at a time.

The secondary bombshell in the advisory is quieter but uglier: once the attacker can peel passwords off the table, "credentials … may be cleartext." No bcrypt, no Argon2, no salted SHA — just passwords sitting in a column, waiting to be read. Two vulnerabilities for the price of one CVE.

What I could and couldn't review

Full disclosure: the GitHub repository linked from the advisory (PilotPatrickk/Published-CVEs) contains only the reporter's markdown advisories, not the ARMS source. ARMS is proprietary software; there is no public fix commit for me to diff, no pre-fix login.php or AuthController.cs to quote line-by-line. git log --all yielded two commits on CVE-2025-59379.md: the initial upload (commit 9931528, 2026-01-05) and a CVSS re-score from 9.8 → 7.5 (commit 373363d, same day). That's the corpus.

So what follows is an analysis of the bug class against the advisory's specifics, not a walk-through of a specific flawed function I laid eyes on. I won't fabricate source that I didn't read.

How the flaw almost certainly looks

Blind SQL injection in a login form is one of the oldest, most catalogued anti-patterns in the canon. The shape is stable across languages. A login handler takes a username and password, builds a query to look up the user, checks the result, and issues a response. The vulnerable version looks — in pseudo-shape, not in actual ARMS code — like this family:

query = "SELECT id, password FROM users WHERE username = '" + user_input + "'"
result = db.execute(query)
if result.row_count == 1 and result.password == hash(input_password):
    login()
else:
    fail()

Three disasters in four lines. (1) String concatenation of user input into SQL. (2) A response that observably differs depending on whether the username half of the query returned a row. (3) The password column ending up in a comparison with something that isn't crypt() or a KDF.

An attacker doesn't need a UNION or an error message to exploit #1 and #2 together. They only need the login page to behave differently when a subquery they injected is true versus false. A sufficiently clever injected expression can pivot on the truth value of arbitrary questions about arbitrary tables — "does the admin user's password start with 'a'?" — and the page's differing behaviour becomes a single-bit side-channel. The attacker reads the whole column one bit per request, with sqlmap doing the arithmetic. This is textbook blind SQLi; I won't write the payload here because reproducing it would hand a reader a weapon, but every database and every web framework documentation's security section describes it.

Why the check was insufficient

The failure mode almost every vendor lands on is "we filter quotes" or "we check for SQL keywords". Blacklist sanitisation fails for the same reason every blacklist fails: the attacker's alphabet is larger than the defender's imagination. ' becomes %27. OR becomes oR or /*!50000OR*/. SELECT becomes SEL/**/ECT. CASE WHEN becomes IF(...). MySQL, MSSQL, PostgreSQL, and SQLite each speak a slightly different dialect, and a parser written to block one is often oblivious to the others.

The only check that works is the one that doesn't parse the input at all: parameterised queries, where the driver sends the query and the arguments down separate wires to the database, and user input is never a SQL token. Anything else — escape functions, prepared-statement emulation at the ORM layer, length limits, character whitelists — is defence in depth at best and security theatre at worst.

The advisory's wording ("via Blind SQL Injection through the user parameter") points squarely at this: input reaches the SQL layer as SQL, not as data.

The second bug, compounding the first

Reading credentials out of the database with blind SQLi is tedious and noisy. It's only catastrophic because the credentials are readable when read. If ARMS hashed passwords with a modern KDF (bcrypt, scrypt, Argon2id, even PBKDF2 with a sensible iteration count), blind SQLi would still leak the hash, but the attacker would then need to crack it — which for a decent password is infeasible, and for any password forces the attacker into a second expensive and detectable phase.

Cleartext-at-rest credentials turn a confidentiality bug into instant credential theft. It's why the CVSS vector lists Confidentiality:High and nothing else: the vulnerability itself doesn't write, doesn't DoS, doesn't escalate — it just reads, but what it reads is enough to walk in through the front door as the admin the next minute.

The lesson here is orthogonal to SQLi: never store anything password-shaped in a form you wouldn't be comfortable reading aloud at a conference. A decade of breach post-mortems have said the same thing, and yet industrial monitoring appliances — precisely the gear that spends five years in a server closet unpatched — keep shipping with reversible password storage.

What a fix would look like

With no fix commit to point at, I can only describe what a responsible remediation looks like for this bug class:

1. Convert the login query to a parameterised statement. In practice this means the query string is a literal constant (SELECT id, password_hash FROM users WHERE username = ?) and the username travels as a bound parameter. No concatenation, ever, for any path.
2. Normalise response behaviour on authentication failure: same status code, same body, same timing — verify_password(stored_hash, supplied_password) runs even when the user doesn't exist, comparing against a dummy hash so that the response time doesn't leak username existence.
3. Hash passwords with a modern KDF and migrate existing accounts on their next login. The cleartext column is not salvageable; it's a liability to every row in it.
4. Rate-limit and lock the login endpoint. Blind SQLi requires thousands of requests; any half-decent rate limit turns a 20-minute extraction into a 20-day extraction and gives the SOC something to alert on.

The lesson

Login pages feel boring, which is why they keep being the attack surface. They are the one HTTP handler that must consult the user database on every unauthenticated request — and that fact makes them the highest-leverage place in the app to get input handling wrong. A blind SQLi in /login is worth more to an attacker than the same bug in almost any other endpoint, because the endpoint is public, unauthenticated, and sitting next to the credential table.

Two rules, neither novel, both apparently still necessary in 2026:

• Parameterise. Every. Query. If your framework makes it easier to concatenate than to parameterise, switch frameworks.
• Your database is not a password safe. Hash with a KDF designed this decade, salt per user, and assume every row will eventually be read by somebody you didn't invite.

ARMS 1.5.7 appears to have violated both. The CVE catches one; the advisory's footnote about cleartext catches the other.

References

• NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-59379
• Reporter's advisory: https://github.com/PilotPatrickk/Published-CVEs/blob/main/CVE-2025-59379.md
• Vendor — Dwyer-Omega brands: https://info.dwyeromega.com/brands
• Product — Isensix Guardian/ARMS: https://isensix.com/guardian/