CVE watch
Is your AWS account exposed to a critical vulnerability?
When a critical vulnerability is published, the real question is: which resources in my account are affected? The Silamir audit answers it for every active alert. It cross-checks Amazon Inspector findings, the SSM software inventory and AWS metadata, then ranks each resource by certainty and exposure.
In short
- Watched products: PHP, OpenSSL, nginx, Apache HTTP Server, Apache Tomcat, Node.js.
- Alerts taken into account: CERT-FR critical alerts and CISA Known Exploited Vulnerabilities (KEV) that affect a watched product. Each one stays active for 90 days; after that, coverage relies on Amazon Inspector.
- One status per resource: confirmed by Inspector, end of life, probable, to be checked or fixed. The ranking is computed by a deterministic program, not by the AI.
- Blind spots become recommendations: an internet-facing instance whose software the audit cannot read (outside SSM or without inventory) is a defect to fix, rated HIGH. Never a "not affected".
Why a dedicated check
On 21 October 2026, PHP released fixes for two vulnerabilities allowing unauthenticated remote code execution (CVE-2026-109618 and CVE-2026-109619, French alert CERTFR-2026-ALE-014). Every version up to 8.1 stays vulnerable. On AWS, PHP can run in very different places: an EC2 instance, an Elastic Beanstalk platform, a Bref Lambda layer, an ECS container image or a Lightsail blueprint.
Native tools only give part of the answer. Amazon Inspector confirms a vulnerability on the instances, images and functions it scans, but it is not always enabled and sees neither Beanstalk platforms nor Lightsail blueprints. Security Hub does not tell which PHP version runs on which resource. The audit's CVE watch brings these sources together into a single answer, resource by resource.
Where the audit looks for watched products
Everything goes through the audit's read-only role: no agent to install, no connection to your instances. One exception, if you enable the DAST scan: one HTTP request per internet-facing server, to read the software it announces.
| Source | What is read | Precision |
|---|---|---|
| Amazon Inspector v2 | Active CRITICAL and HIGH findings on EC2, ECR and Lambda | CVE confirmed on the resource |
| AWS Systems Manager Inventory | Packages installed on each SSM-managed instance | Exact package version |
| Elastic Beanstalk | Language version of each environment's platform | Exact version or branch |
| AWS Lambda | Layers attached to functions (for example Bref for PHP) | Branch (e.g. 8.3) |
| Amazon ECS | Task definition images (e.g. php:8.2.34-apache) | Exact version with a full tag, branch otherwise |
| Amazon Lightsail | LAMP, WordPress, Drupal, Joomla, Magento, PrestaShop and nginx blueprints | Presence, sometimes branch |
| HTTP headers (with the DAST scan) | Server and X-Powered-By headers of internet-facing servers (e.g. PHP/8.1.2), one request per server | Announced version, always "to be checked" |
Five statuses, from most to least certain
- Confirmed: Amazon Inspector reports an active finding on one of the alert's CVEs for this resource.
- End of life: the installed branch no longer gets vendor fixes (PHP 8.1 and older in the 2026 alert). Exception: a distribution package (Ubuntu, RHEL…) may still be patched by the distribution, so it is rated "to be checked".
- Probable: the exact version is known, lower than the fixed version, and does not come from a distribution package.
- To be checked: only the branch is known, or the version comes from a distribution package (Ubuntu, RHEL…) that may have received the fix without a version change. The audit reports it without concluding, and says when Inspector scans the instance without reporting anything.
- Fixed: the installed version is at least the fixed version. These resources are counted, not listed.
Exposed or internal: severity follows exposure
A vulnerable resource reachable from the internet is not the same risk as an internal instance. The audit determines exposure from the network configuration.
- EC2: public IP with a security group open to the internet on web ports, or target of an internet-facing load balancer.
- Elastic Beanstalk: Web Server environment. Lightsail: public IP.
- Lambda: Function URL without authentication. ECS: service behind an internet-facing load balancer.
- Severity: CRITICAL for a confirmed, probable or end-of-life resource that is exposed, HIGH when internal. A resource to be checked is HIGH when exposed, MEDIUM otherwise.
What the report contains
- One finding per alert in the security report, listing the affected resources with their version, status and the reason for their exposure.
- The vendor's interim measures, as a priority action when a resource is exposed (for PHP: disable
session.upload_progress, cap request size at the proxy…), then the permanent fix. - Coverage recommendations, each with its severity and action: internet-facing instances outside SSM or without software inventory (HIGH), internal instances in the same case (LOW), Amazon Inspector disabled in a region (HIGH if it hosts an exposed instance, MEDIUM otherwise).
- Other critical vulnerabilities reported by Inspector, even outside any alert, ranked by whether a public exploit exists.
These findings feed the audit's attack chains and remediation plan, delivered with the rest of the reports for 299 USD per audit.
How alerts are kept up to date
The alert catalogue is updated daily from public sources, with a cautious rule.
- Detection: the CERT-FR alert feed and the CISA KEV catalogue, filtered on the watched products.
- Fixed versions: the vendor's GitHub security advisories, the NIST NVD and OSV.dev, checked against the versions actually released (endoflife.date).
- Validation: an alert is added automatically only when two independent sources give the same fixed versions. In every other case, a member of the Silamir team reviews it before publication.
- Publication: a validated alert applies from the next audit, without waiting for a new release of the service.
What the CVE watch does not do
- It is not a vulnerability scanner: the audit connects to no instance and sends no malicious payload. Without Inspector or SSM, it can only see that a product is present; with the DAST scan, it also reads the version announced by internet-facing servers, without being able to guarantee it (a server can hide or forge it).
- Products that are not watched are covered only through the account's Inspector findings.
- Distribution backports are not interpreted: a package version lower than the fixed version stays "to be checked" until Inspector or the distribution's advisory settles it.
- The audit is a snapshot: it does not replace continuous monitoring. For that, enable Amazon Inspector across all your accounts.
CVE watch: frequently asked questions
Which products does the CVE watch follow?
PHP, OpenSSL, nginx, Apache HTTP Server, Apache Tomcat, Node.js. Vulnerabilities in other software show up in the report through Amazon Inspector's CRITICAL and HIGH findings, when Inspector is enabled.
Do I need Amazon Inspector to benefit from it?
No, but it is recommended. Without Inspector, the audit relies on the SSM inventory and AWS metadata, so it can never confirm a CVE. It then rates resources as probable, to be checked or end of life, and reports the missing Inspector as a blind spot.
Do I have to install an agent on my instances?
No. The audit reads what the SSM agent, preinstalled on recent Amazon Linux, Ubuntu and Windows AMIs, publishes to Systems Manager Inventory. SSM Inventory must still be enabled (Quick Setup or State Manager): an instance without the agent, or managed by SSM without inventory, cannot be checked. The audit reports it as a defect to fix, with priority when the instance is internet-facing. If you enable the DAST scan, the audit also reads the HTTP headers of these servers to spot the software they announce.
Can the AI get a version wrong?
Version comparison is done by a tested, deterministic program before the AI is called. The AI receives the result with the instruction to copy statuses and severities as they are, and to call no other resource vulnerable.
How soon after an alert does the audit take it into account?
The watch runs daily. An alert whose fixed versions match across two sources is published the same day, with no human step. The others are published after a review by the Silamir team. Either way, the alert applies from the next audit.
Where does your AWS account stand?
Ten questions, three minutes, no access to your account: a security score, a FinOps score and the article to read for each of your three weakest points. Your answers stay in your browser.
Ready to audit your AWS account?
Subscribe on AWS Marketplace, deploy the read-only role and get your reports within the hour.