Blog
Keeping systems up to date is a security control, not a chore
Senior Cloud Architect
October 2026 showed how quickly a working server can become an open door for attackers. In just one week, two critical vulnerabilities came to light: PHP2Shell and Node2Shell. Both can allow attackers to run their own code on affected systems, and both were actively exploited shortly after disclosure.
The good news for our customers is that much of the protection is already in place. We automatically apply security updates to the systems we manage for you. However, automatic updates have their limit: they can only install patches that are available. Once an operating system reaches end of life (EOL), it no longer receives security patches, and that’s where the risk begins.
What happened
PHP2Shell (CVE-2026-109618, CVE-2026-109619) refers to two memory-safety vulnerabilities in the PHP interpreter. They affect PHP versions 5.4 through 8.5, spanning more than a decade of releases. An unauthenticated web request can execute code on the server or access sensitive information in memory such as passwords, tokens, and keys. Because the flaws exist in the PHP runtime rather than in the application code, even well-written applications can be affected. The US Cybersecurity and Infrastructure Security Agency (CISA) lists both vulnerabilities in its Known Exploited Vulnerabilities (KEV) catalog.
Node2Shell (CVE-2026-111497) affects Brotli, a widely used compression library. Specially crafted compressed data, such as data contained in a request or response, can cause a process to crash, expose sensitive information in memory or allow attackers to execute arbitrary code. Node.js bundles Brotli, but it’s also distributed as a system library and used by many other applications. CISA added this vulnerability to its KEV catalog on October 27, 2026.
How we protect your systems
We run your environment on AWS, including orchestration, deployment, and configuration. On every system we manage, security updates are automatically installed using unattended-upgrades. When the operating system vendor publishes a fix, it reaches your servers without any action required on your part. For PHP2Shell and Node2Shell, this meant that systems running supported OS releases received the patched packages shortly after they became available through their distributions.
Where automatic updates stop
Automatic updates keep a system up to date within its current OS release. They don’t upgrade it to a newer release. Upgrading can affect runtime versions, libraries, and system behavior, which is why careful planning and testing with you are essential.
Running an EOL operating system has three major consequences:
- The OS vendor no longer publishes security fixes, leaving unattended-upgrades without new patches to install.
- Runtimes provided by the OS, such as PHP, remain on the vulnerable version indefinitely.
- Each new vulnerability that is discovered adds to the existing ones, and none of them are fixed.
How you deploy your application also determines who can apply a fix:
- Source code deployments: your code runs on servers we manage. The OS and the runtimes provided by it are patched automatically for as long as the OS release is supported.
- Container images on Elastic Container Service (ECS): we keep the infrastructure that runs your containers up to date. Everything inside the image, including its base OS, PHP or Node.js version, and libraries, comes from the image you provide. Patching the host doesn’t fix a vulnerable image. Your images need to be rebuilt using current, supported base images and redeployed.
Additional protection with AWS services
Patching fixes vulnerabilities. Additional AWS security services buy time until a patch is available and help detect attacks that get through anyway. We can add them to your managed infrastructure:
- AWS Web Application Firewall (WAF) filters malicious requests before they reach your application. It runs in front of CloudFront, Application Load Balancers or API Gateway. AWS keeps its managed rule groups up to date, and published WAF mitigations for PHP2Shell on the day of disclosure. This kind of “virtual patching” protects you while updates are rolled out, but it doesn’t replace them.
- Amazon GuardDuty continuously analyzes your AWS environment for signs of attack, such as connections to known malicious hosts or unusual API activity. With Runtime Monitoring, it also monitors EC2 instances and ECS containers for suspicious behavior, such as reverse shells or crypto miners following a successful exploit.
- Amazon Inspector continuously scans EC2 instances and container images in Amazon Elastic Container Registry (ECR) for known vulnerabilities. When a new Common Vulnerabilities and Exposures (CVE) entry is published, it identifies which systems and images are affected, including those already in production.
- AWS Security Hub brings together and prioritizes findings from these services, giving you a single overview instead of multiple separate consoles.
These services complement up-to-date systems, but they don’t replace them. An EOL system behind a WAF is still an EOL system.
What we recommend
- Stay on a supported OS release. This is the minimum level of protection and the only way to ensure that automatic security updates can do their job.
- Plan upgrades before EOL, not after. We’re happy to tell you the support status of your current systems and the relevant end-of-life dates.
- Use CI/CD pipelines wherever possible. Automated builds and deployments make updates routine instead of risky. A pipeline builds, tests, and rolls out changes the same way every time, making it easy to roll back if something goes wrong.
- Build security scans into the pipeline. Tools like Trivy check container images, dependencies and configuration for known vulnerabilities before anything reaches production. Set the pipeline to fail on critical findings. Run scheduled scans on images that are already deployed so you can identify new CVEs affecting code that hasn’t changed. Pin your pipeline tools, including the scanners, to immutable references such as a commit SHA or image digest rather than a version tag, so the toolchain itself stays trustworthy.
- Keep your dependencies current automatically. Your application’s dependencies, such as Composer or npm packages and container base images, change constantly. Together, they make up your software bill of materials (SBOM), an inventory of all components in your software. Tools like Dependabot or Renovate monitor these dependencies and automatically open pull requests when updates are available, with security fixes clearly flagged. Combined with a CI/CD pipeline and automated tests, applying an update often just means reviewing and merging a pull request.
- Rebuild container images regularly. Use maintained base images and rebuild them even if your code hasn’t changed, so that security fixes are included. A CI/CD pipeline makes this a scheduled job rather than a manual task.
- Talk to us early. An OS upgrade is a joint project. We set up a staging environment, you test your application for compatibility (automated tests in your pipeline speed this up considerably), and together we agree on a maintenance window for the switch to production. The earlier we start, the less pressure there is when the next critical vulnerability is published.
The bottom line
PHP2Shell and Node2Shell won’t be the last vulnerabilities of their kind. On the systems we manage, we’ll keep installing security fixes automatically as soon as they’re available. Your part is to make sure fixes keep coming by staying on supported OS releases and up-to-date images. If you’re running an older OS release or using older container images, contact us and we’ll plan the upgrade together.
We can also help with any of the other topics covered in this post. That includes checking the support status of your systems, setting up CI/CD pipelines, adding security scans with Trivy and configuring Dependabot or Renovate. In addition, we can extend your environment with AWS WAF, GuardDuty, Inspector and Security Hub. Just get in touch through our service portal, and together we’ll find the right approach for your environment.
Contact
Want to know more about AWS Managed Services?
