Vulnerability intelligence

Check your exposure

Vulnerability Intel compares the versions your sites and servers report with published affected ranges and shows what needs an update, and to which version. A component is listed only when its reported version falls inside a published range; an advisory without a range never marks anything affected.

• Update needed: the reported version is inside an affected range. The fix shown is the first fixed release on your branch, for example 8.3.36 for PHP 8.3.
• Check vendor: a distribution build, such as PHP 8.1.2-1ubuntu2.20. Distributions backport fixes without changing the upstream number, so follow your vendor's security notice for that package.
• Stale report: nothing has been reported for more than seven days, so the result may be out of date.
• Known exploited: the CVE is on CISA's Known Exploited Vulnerabilities list.
• Seen on your sensors: in the last 30 days, a ModSecurity rule written for that CVE fired on one of your own sensors, under the rules in Exploitation evidence. Seen across Witen means the same kind of hit came from at least three sensors across the network.

Linux packages are judged by your distribution's own fixed versions, not upstream ones, for Debian, Ubuntu, Alpine, Gentoo, and Red Hat Enterprise Linux and its rebuilds. How Linux packages are judged lists each source and the notices you'll see.

Turn on inventory reports

Witen Blocker reports your WordPress and PHP versions on its own. Plugin, theme, and package lists are off until you turn them on, and only names and versions are sent: no file contents, settings, or user data.

[inventory]
enabled = true
interval_sec = 86400

How Linux packages are judged

Each installed package is compared with its own distribution's fixed versions, using that distribution's version rules (dpkg, rpm, apk, or Portage). Each finding is a CVE that links to the notice that fixes it.

Alpine's release list is read from secdb itself, so a new Alpine release is covered as soon as Alpine publishes its data. After the first read, every source stays current daily.

Where the data comes from

• PHP: the PHP project's own security advisories from php-src, with exact ranges for each supported branch on the day of release.
• WordPress core: the WordPress project's own advisories from wordpress-develop and the WordPress.org security release feed, which is also kept as its own records.
• Plugins, themes, and other platforms: the National Vulnerability Database, read every six hours. OSV adds advisories for WordPress core and a short list of widely used web frameworks.
• Exploitation: CISA's Known Exploited Vulnerabilities catalog, and qualifying WAF hits from Warden sensors.
• Linux packages: the Debian, Ubuntu, Alpine, Red Hat, and Gentoo security trackers, read daily. See How Linux packages are judged.

Read the advisory model

An advisory is a sourced security publication, not merely a CVE row. WordPress.org may confirm several issues in one release while assigning a public identifier to only some of them. Witen preserves the publisher, canonical source URL, retrieval time, evidence class, and confidence instead of inventing missing identifiers.

• Publisher confirmed means the component publisher publicly confirmed the claim.
• Coordinated disclosure means Witen validated the issue with the affected vendor before publication.
• Independent reproduction means Witen reproduced the issue in an authorized isolated environment.
• Third-party reports and observed suspicious behavior do not become confirmed vulnerabilities by themselves.

Treat version evidence conservatively

Affected and fixed versions are separate claims. A security release proves that its release contains a fix; it does not automatically prove that every earlier version is affected.

Understand lifecycle changes

Interpret observed exploitation

Known exploited comes from CISA. Seen on your sensors and Seen across Witen come from ModSecurity rule hits that Warden reports, from the last 30 days. A hit marks a CVE observed only when all three of these hold:

• The rule was written for that CVE. Rules that match a shape ordinary traffic also sends, and threshold or anomaly rules, stay listed as detections but never mark a CVE observed. In the PHP2Shell examples, only rule 9420000 (CVE-2026-109619) qualifies; 9420001 to 9420003 do not. Warden's built-in exploit classifications are listed as detections too, and don't mark CVEs observed.
• It came from ModSecurity, the engine the rule mappings are written for. Coraza findings never count, in any mode.
• The engine was enforcing (SecRuleEngine On), or the sensor is one of Witen's own verified sensors. A DetectionOnly, disabled, or unknown engine mode on any other sensor doesn't count. Warden reads the mode from the JSON audit log. The Apache error-log input shows it only on lines that record a denial, so pass-and-log rules read that way, the PHP2Shell examples included, never count.

Seen across Witen needs qualifying hits from at least three distinct sensors, counting each customer and sensor pair once. The same three rules apply to every one of them.

• Displayed values are aggregate event, sensor, and source-address counts.
• Customer IDs, hostnames, raw requests, user agents, source addresses, cookies, and credentials are not published.
• No visible match means Witen has no qualifying evidence; it does not prove exploitation is absent.
• Classifier validation accounts for CDNs and shared clients, so shared infrastructure is not mistaken for one malicious identity.

Respond to an advisory

1. Confirm the component and installed version on every protected asset.
2. Follow the publisher's fixed-version guidance when it is available.
3. Back up and stage the update according to the component vendor's procedure.
4. Use Witen Activity and local Warden evidence to investigate matching behavior; do not use aggregate network counts as attribution.
5. Document the update and verify the component version after deployment.

Open Vulnerability Intel

Report a vulnerability

Email security@witenlabs.com with the affected component and versions, reproducible steps, impact, and your preferred disclosure terms. Do not send credentials, production personal data, or exploit traffic against systems you do not own or have permission to test.