Finding an exposed system is the easy part. Getting the fix approved and into production is where most of the risk actually lives.
The Hacker News ran a piece this week on why urgent security fixes sit unpatched, and it lays out a four-stage remediation model: Observe, Prove, Act, Confirm. The core point is right. Operations teams hold back changes because they need evidence a fix won't break production, and security teams rarely hand them that evidence in a form they can act on.
The model is built for enterprise tooling, though. If you're a security team of one or two people protecting critical systems, you don't need a framework. You need a short, repeatable way to ask for a change and get a yes.
Why urgent fixes stall
Security's job isn't to produce reports of exposed systems. It's to make sure that exposure actually goes down. Lately the conversation has centered on patching, and on how long the gap is growing between discovering a vulnerability and closing it.
The reality is that every organization balances uptime against security exposure. Most won't push an update without proof the system won't be impacted. Then the political questions start: How likely is this to happen? What's the impact if it does?
Those are fair questions. But for a team of two, answering them through a long review cycle can take weeks, and the system stays exposed the whole time. That's where the drift sets in between leadership, operations and security, each waiting on the other.
The checklist: six steps to a patch approval
When you hit resistance getting a patch or change approved, work through these in order. Each step answers a question leadership or operations is going to ask anyway.
Validate what's exposed. Confirm which systems are actually reachable and vulnerable, not just flagged by a scanner.
Define the impact. State plainly what happens if that system is compromised through this vulnerability. That's your "what's the impact" answer.
List current controls. Gather what already reduces the likelihood today: firewall policy, IPS signatures, segmentation, WAF rules, EDR.
Gather the fix. Collect the vendor patch, or the configuration change that reduces the risk if a patch isn't ready yet.
Build a one-page report. Keep it short and straight to the point: exposure, current controls, proposed changes, expected result, and a suggested change window.
Monitor and capture the results. After the change, collect the logs that show attacks being blocked, and keep collecting them over an extended period.
Steps 1 through 5 get you the approval. Step 6 is what gets you the next one faster.
What the one-page report looks like: PHP2Shell
Here's step 5 using this month's PHP2Shell flaws (CVE-2026-109618 and CVE-2026-109619) as the example. They sit in the PHP engine itself, affect every version back to 5.4, and let an unauthenticated attacker read worker memory and, in some cases, run code. Patched builds shipped October 21.
Section | What to write |
Exposure | Public web server running PHP 8.3 behind Apache, reachable on 443. Confirmed vulnerable build. |
Impact | Unauthenticated remote code execution. Credentials, tokens and API keys in PHP memory can be read. Server is a pivot point into the internal network. |
Current controls | Firewall limits inbound to 443. IPS profile applied to the web policy. Server sits in a DMZ segment. |
Proposed changes | Upgrade to PHP 8.3.36. Until then, enforce any available IPS or virtual-patch signature on the web policy. After patching, rotate secrets stored on the server. |
Expected result | Vulnerability closed at the source. Interim signature blocks known exploit traffic. Any secrets already exposed are invalidated. |
Change window | Tonight's maintenance window. Rollback: previous PHP package and config snapshot. |
One caution from the source article worth repeating: an IPS signature or virtual patch is a stopgap, not a fix. Track it separately so nobody marks the vulnerability closed while the old PHP build is still running. On PHP 8.1 or older there's no official patched release at all, so the real fix is an upgrade.
After the change: logs are your proof of value
The hardest thing in security is showing a business tangible results. When defense works, nothing happens, and "nothing happened" is a tough line item to defend.
That's why step 6 matters. Once the change is in, monitor the system and capture the logs that show blocked attempts against it: IPS hits, denied connections, exploit signatures matched. Keep collecting for weeks, not days. For PHP2Shell, that means watching for malformed multipart uploads, bursts of HTTP 500 errors, and PHP workers spawning child processes.
A short follow-up showing "this many exploit attempts blocked since the change" does two things. It shows leadership what their approval bought. And it makes the next change request easier, because now you have a track record.
The AMIS take
Reporting and monitoring are how an organization sees the value of its security team without getting hacked first and calling that team in a panic to restore systems. A simple, consistent change request turns security from the team that slows things down into the team that shows its work.
Sources
Why Urgent Security Fixes Aren't Fixed. Observe, Prove, Act, Confirm Gets Them Moving, The Hacker News (contributed partner piece)
PHP2Shell: One Upload, Full Server, Varonis Threat Labs
SOURCE / FORTINET ANNOUNCEMENT
This is AMIS’s independent perspective, not a Fortinet datasheet or a performance guarantee. Validate specifications, availability, and licensing before making a purchasing decision.