Jesse Barker, Red Hat Practice Director, IIS Technology Solutions
The next vulnerability won't wait for your change window
When leadership asks whether you're exposed and how quickly you can fix it, a patch notification isn't an answer. You need a response your teams can trust and execute.
The PHP vulnerabilities Red Hat published on October 21, 2026 under RHSB-2026-013, Request handling memory corruption – php (“php2shell”) are a timely example. Red Hat lists Red Hat Enterprise Linux 7 through 10 as affected, along with layered products that pull packages from the Red Hat Enterprise Linux channel, including Red Hat OpenShift Container Platform.
Red Hat’s analysis also shows that real exposure depends on how PHP is deployed. Red Hat Enterprise Linux 8 and later default to PHP-FPM rather than mod_php, which changes the risk picture considerably. At the time of writing, Red Hat lists the bulletin as ongoing and is expediting fixes, so check the bulletin directly for current status.
Knowing a fix exists is not the same as being ready
That nuance is where many organizations struggle. Knowing a fix exists is different from knowing which systems need it, who owns them, which business services depend on them, and how to change them safely.
A supported enterprise foundation and an executable response plan serve different purposes. The foundation keeps the environment your business depends on secure and supportable. The response plan defines how your teams assess exposure, make changes, and confirm the outcome. Readiness is what connects the two: the difference between having technology deployed and having an operational capability you can rely on.
From a finding to a governed change
Red Hat already provides much of the tooling. Red Hat Lightspeed (formerly Red Hat Insights), included with Red Hat Enterprise Linux, identifies affected systems and can generate Ansible Playbooks for supported findings. Those playbooks can then run through your Red Hat Ansible Automation Platform workflows.
Red Hat Ansible Automation Platform adds the controls a security response needs, including role-based access control and audit trails. Red Hat’s approach to security automation extends the same model so security and IT operations teams work from one coordinated response. Responding quickly should not mean abandoning governance.
What the tooling doesn’t provide is the process around it. A generated playbook still needs someone to confirm it applies, understand the operational impact, schedule the change, and verify the result.
Turning a response plan into a repeatable workflow
When a vulnerability demands action, organizations need more than a collection of scripts. They need an agreed process that teams can execute without losing accountability. We structure vulnerability response automation in five stages:
- Establish scope. Gather the system, package, configuration, and container image data needed to know what is actually exposed, not just what is installed.
- Prioritize action. Weigh technical exposure against application ownership, business importance, and maintenance constraints.
- Execute approved changes. Apply tested remediation in controlled groups, with the approvals your change process requires.
- Validate the outcome. Check both system state and application health. A successful automation job doesn’t prove the business service is healthy.
- Record and improve. Capture results, work through exceptions, and refine the workflow before the next bulletin arrives.
Event-Driven Ansible can shorten the time between a finding and a response by starting the right workflow from an incoming event, while still routing high-impact changes through human approval.
None of this works as a generic template. Workflows have to be designed around your environment, tested against application dependencies, and maintained as systems change. Automation makes a defined process repeatable. It doesn’t define the process for you.
How IIS helps
As a Premier Red Hat Partner, IIS Technology Solutions helps customers turn Red Hat platform capabilities into an operational discipline. We rarely start with “what can we automate?” We start with where the response breaks down today.
Sometimes security can identify exposure, but operations translates findings into changes by hand. Sometimes patching is automated, but application validation isn’t. Often the response depends too heavily on which engineer happens to be available. Our engagements follow a consistent path:
- Understand. We review how your response works today, including ownership, visibility, handoffs, and execution.
- Explore. We look at where Red Hat Ansible Automation Platform, Event-Driven Ansible, and Red Hat Lightspeed fit your environment and requirements.
- Validate. We prove a bounded use case, such as Red Hat Enterprise Linux security patching, in a hands-on workshop or proof of concept.
- Implement. We put the workflow into production with the governance, roles, and measures that let you expand it with confidence.
The goal isn’t to automate every decision. It’s to automate the repeatable work so your people can focus on the decisions that need judgment.
The next headline should trigger a plan, not a scramble
You can’t control when the next vulnerability is disclosed. You can control how much of your response is already mapped, tested, and rehearsed. When leadership asks whether you’re exposed, the answer should come from a process your teams trust, not a spreadsheet assembled overnight.
If a critical vulnerability were disclosed tomorrow, would your team be running a tested plan, or building one while the clock runs?
To schedule a consultation with the IIS Red Hat team, contact redhat@iisl.com.
Jesse Barker is Red Hat Practice Director at IIS Technology Solutions.
IIS Technology Solutions is a proud partner of Red Hat, the world’s leading provider of enterprise open source software solutions.
