What this checks: whether a Roundcube Webmail host runs a version affected by unauth version fingerprint of a SQL-injection-vulnerable Roundcube build. Read-only: it fingerprints Roundcube Webmail and reads the version, no exploitation.
3. Detection — reads the Roundcube Webmail version from the version exposed at /?_task=login, compares to 1.3.17 (1.3.x) / 1.4.12 (1.4.x); 1.5.0 and later already contain the fix. Flags vulnerable on an affected build. No exploitation.
1. Target List — paste your Roundcube Webmail URLs here, one per line (e.g. https://host.example.com).
Overview
This workflow finds Roundcube Webmail and sorts each host by whether its version falls below the CVE-2021-44026 fixed floors. CVE-2021-44026 is SQL injection through Roundcube search parameters. This check never sends a search query and never injects SQL. Give it hostnames, IP addresses, or URLs you are authorised to test. The workflow GETs /?_task=login, fingerprints Roundcube from page markers, reads the version from the login page, and compares it to the per-branch table in the graph. Every host comes back affected or not, so a fleet advisory becomes an evidenced list for exposure management. Hosts that hide their version stay product-detected without a vulnerable flag.
Run it on a schedule when webmail frontends change. A forgotten Roundcube 1.4.x box is the reason the same fingerprint is worth more the second week than the first.
Pipeline
Read the target list. Hosts, URLs, or ranges, one per line, become the scope.
GET /?_task=login on each host and fingerprint Roundcube from markers such as Roundcube, rcmail, and the generator meta tag.
Parse the version from the login page and compare it to the CVE-2021-44026 per-branch floors in the graph.
Collect the per-host rows: product match, version, vulnerable flag, and any fetch error.
Emit the summary counts: hosts checked, product hits, vulnerable, and errors.
Inputs
Target scope. Hostnames, IP addresses, CIDR ranges, or URLs, one per line. Full URLs and host:port entries work too, since the workflow normalizes each into a bare host. Point it at scope you are authorised to test.
Outputs
results.jsonl. One row per host: URL, whether Roundcube was detected, the version read, the vulnerable flag, and detail text.
findings.jsonl. The same per-host verdict shaped for triage, with severity set from the vulnerable flag.
summary.json. Counts across the list: targets, product hits, vulnerable, and errors, plus the detection notes from the graph.
Integrations
HTTP. Unauthenticated GET of /?_task=login only. No SQL injection payload and no CHANGELOG fetch.
Sample output
The records below are illustrative and do not come from a real run. They show one Roundcube host below a branch floor, one at or above its floor, and one host that is not the product.
Builds below the per-branch floors in the graph: 1.3.17 on the 1.3.x line and 1.4.12 on the 1.4.x line. 1.5.0 and later are treated as fixed. The compare uses the version the login page itself served.
Does an affected row mean SQL injection worked?
No. The check only GETs /?_task=login and reads the version. It does not send a search parameter and it does not confirm SQLi.
Is this check safe on production?
Yes. It is a read-only unauthenticated GET of the public login page. It does not log in or touch the mailbox database.
Does the check need credentials?
No. It fingerprints the public login page the way an external scanner would.
What is CVE-2021-44026?
SQL injection in Roundcube Webmail through search parameters. This workflow maps hosts to that CVE by version exposure only.