Coder Legion - Recent posts tagged cve

PHP2Shell: When a Simple Upload Feature Turns Into Remote Code Execution

Sat, 31 Oct 2026 12:16:03 +0000

Exploring CVE-2026-109618 and CVE-2026-109619 through a TryHackMe lab.

Introduction

October is Cybersecurity Awareness Month, and honestly, this month has been quite interesting from a cybersecurity perspective. There have been plenty of vulnerabilities, attacks and security incidents worth paying attention to.

But while going through TryHackMe, something particularly caught my attention: PHP2Shell.

At first, I was interested in the upload exploitation technique. I mean, how does something as ordinary as a file upload eventually lead to remote code execution?

That question made me curious enough to investigate further.

On October 21, 2026, two critical vulnerabilities were disclosed in PHP: CVE-2026-109618 and CVE-2026-109619. Together, they demonstrated how an unauthenticated attacker could potentially execute operating system commands on a vulnerable PHP server through specially crafted HTTP requests.

And here's the part I found most interesting:

The application itself didn't even need to be vulnerable.

The weakness existed inside PHP's runtime, meaning that even an application with perfectly ordinary PHP code could potentially be affected.

So, I decided to explore the vulnerability through a TryHackMe lab and understand what was actually happening behind the scenes.

Let's break it down.

1. First, what exactly is PHP2Shell?

PHP2Shell is the name given to a pair of vulnerabilities affecting the PHP runtime.

CVE	Description
CVE-2026-109618	Remote code execution via out-of-memory (OOM) handling and request-state corruption
CVE-2026-109619	Remote code execution via stale global state and use-after-free

Both vulnerabilities received a CVSS v4.0 score of 9.2 (Critical).

The vulnerabilities involve PHP's internal request-processing and memory-management mechanisms.

What makes this particularly concerning is that the vulnerable code isn't necessarily part of the application developers write. It exists deeper inside the PHP engine.

So, updating your WordPress installation or fixing your Laravel application wouldn't automatically resolve the underlying problem.

To understand why, I first needed to understand the PHP feature involved in the exploitation.

2. The interesting part: PHP Upload Progress

The TryHackMe exploitation scenario explores PHP's session.upload_progress functionality as part of the attack path.

PHP provides this feature to track file uploads.

Imagine uploading a large file through a website. You might see a progress indicator showing how much of the file has been uploaded.

PHP can help provide this information by tracking details such as:

Uploaded file name.
Total upload size.
Amount of data received.
Current upload progress.

The relevant configuration directive is:

session.upload_progress.enabled = On

And the default form field responsible for activating this functionality is:

PHP_SESSION_UPLOAD_PROGRESS

Now, here's where things get interesting.

PHP processes this upload-progress information while parsing an incoming multipart/form-data request.

That happens before the application script actually starts executing.

In simpler terms, PHP is already processing the upload before the website's own PHP code gets control.

This means the relevant request-processing functionality can be reached without the target page necessarily implementing its own file-upload feature.

I found this particularly interesting because it changes how we think about the attack surface.

We normally think about vulnerabilities in terms of application code, authentication systems and user input validation.

3. Understanding the actual memory-management bug

This was probably the part that required the most attention from me.

To understand PHP2Shell, I needed to understand what happens when PHP runs out of memory.

PHP has a configuration directive called memory_limit, which restricts how much memory a request can consume.

When a request exceeds that limit, PHP can trigger something called a bailout.

Internally, the engine uses longjmp() to escape the current execution path after certain fatal errors.

Normally, software should clean up its resources properly when an operation finishes.

However, an emergency bailout can interrupt normal request processing and leave internal state in an incomplete condition.

This is where PHP2Shell becomes interesting.

CVE-2026-109618: Out-of-memory handling

In this vulnerability, an out-of-memory condition can interrupt PHP while request data is only partially initialized.

The bailout can leave PHP's internal request state inconsistent. When subsequent cleanup operations process that incomplete state, memory corruption can occur, potentially leading to remote code execution.

CVE-2026-109619: Stale global state and use-after-free

The second vulnerability involves a different memory-management problem.

Request-owned memory can be freed while stale global state continues to reference it.

If a later request is handled by the same worker before that state is properly reinitialized, PHP may access memory that is no longer valid.

This creates a use-after-free condition.

Why is a use-after-free dangerous?

Think of memory as a collection of storage locations.

A program allocates a location, stores information there and keeps a pointer to access it later.

Now imagine that the location gets freed, but the program still has the old pointer.

Another allocation might eventually reuse that same memory location.

The original pointer now references something different from what it was supposed to reference.

That's the fundamental problem behind a use-after-free scenario.

The Apache worker connection

The lab uses Apache with mod_php in a prefork configuration.

In this setup, an Apache worker can process multiple requests during its lifetime.

That means internal state left behind by one request can potentially affect a subsequent request handled by the same worker.

This is particularly relevant when understanding the stale-state issue in CVE-2026-109619.

So, the issue isn't simply that PHP encounters an error.

The problem is that internal memory and request state can remain inconsistent or stale in ways that influence subsequent processing.

And this is what makes the exploitation chain possible.

4. Understanding the two vulnerabilities

Now that we understand the different memory-management problems, let's look at how the two CVEs fit into the bigger picture.

CVE-2026-109618: RCE via Out-of-Memory Corruption

This vulnerability involves PHP's handling of an out-of-memory condition during request processing.

An OOM-related bailout can interrupt PHP while internal request data is only partially initialized.

Subsequent cleanup may then operate on invalid or incomplete state, potentially resulting in memory corruption and remote code execution.

CVE-2026-109619: RCE via Stale Global State

The second vulnerability involves stale internal state that survives after the memory backing it has been freed.

When a later request is handled by the same worker, PHP may access that stale state before it has been properly reinitialized.

This creates a use-after-free condition that can ultimately be exploited to achieve remote code execution.

Where the lab's memory-disclosure stage fits

In the TryHackMe exploitation walkthrough, the exploit first obtains information about the PHP worker's memory layout.

The interesting part is where this information gets returned.

PHP uses the following HTTP response header:

Set-Cookie: PHPSESSID

The resulting oversized session identifier can expose adjacent process memory.

That memory may contain useful information, including heap and library addresses.

Why does that matter?

Because modern operating systems use a security mechanism called Address Space Layout Randomization (ASLR).

ASLR randomizes memory locations to make exploitation more difficult.

An attacker generally needs to know where important functions and memory regions are located to reliably manipulate execution.

In the TryHackMe lab, the exploitation chain obtains two important addresses:

The PHP heap base address.
The libphp base address.

This information becomes useful in the next stage.

The important distinction is that this memory-disclosure stage is part of the exploitation chain demonstrated in the lab. It should not be confused with the primary vulnerability classification of CVE-2026-109618, which is remote code execution.

The HashTable and pDestructor technique

This is where things get considerably more interesting.

The lab's exploitation chain uses a forged internal PHP structure called a HashTable.

One of the important fields involved is:

pDestructor

This field is associated with the function PHP calls when destroying certain values.

The demonstrated exploitation technique manipulates this structure to redirect the cleanup process toward the system() function inside PHP's library.

Instead of executing the expected cleanup operation, PHP ends up invoking a function capable of executing operating-system commands.

And that's how the memory manipulation in the demonstrated chain can ultimately result in remote code execution.

What I found particularly interesting is that the normal cleanup process itself becomes part of the exploitation chain.

Something designed to manage resources properly can become dangerous when the underlying memory state has been corrupted.

It's worth remembering that these HashTable and pDestructor details describe the exploitation technique demonstrated in the lab, rather than a universal explanation of the root cause of both CVEs.

5. My practical investigation on TryHackMe

After understanding the concepts, I moved on to the practical investigation.

The TryHackMe room provided a vulnerable PHP server running inside a Docker container.

I connected to the machine using SSH with the provided credentials.

The first thing I wanted to do was identify the running container and check its PHP version.

I used:

docker ps --format '{{.Names}} {{.Image}} {{.Status}}'

The output showed:

php2shell-target php:8.4.26-apache Up

Next, I checked the PHP version inside the container:

docker exec php2shell-target php -v

The target was running:

PHP 8.4.26 Zend Engine v4.4.26

This was important because PHP 8.4.27 was the fixed release.

So, the lab environment was running a vulnerable version.

Inspecting the application

Next, I wanted to see what the actual website was returning.

I executed:

curl -s http://127.0.0.1:8088/index.php

The response?

OK

That's it.

I also inspected the PHP file:

docker exec php2shell-target cat /var/www/html/index.php

And found:

<?php echo "OK\n"; ?>

At this point, I found the situation particularly interesting.

There was no login system.

There was no database.

There was no application-level file-upload functionality.

The application was literally printing OK.

Yet the underlying PHP runtime was vulnerable.

This reinforced one of the biggest lessons from the room: an application doesn't necessarily need to contain vulnerable code for its underlying server to be exploitable.

6. Observing the memory disclosure

After confirming the target environment, I moved to the memory-disclosure stage.

The lab provided an existing exploit repository:

php2shell-bypass-aslr-exp

I navigated into the directory:

cd ~/php2shell-bypass-aslr-exp

The provided exploit handled the exploitation stages.

I ran it against the local target:

python3 exploit.py -u http://127.0.0.1:8088/index.php

The output showed two particularly interesting stages:

`[*] stage 1: heap leak
[+] chunk base = 0x...

[*] stage 2: libphp leak
[+] libphp base = 0x...`

These were the two memory addresses the exploitation chain needed.

The first revealed the heap location, while the second revealed the PHP library's base address.

I found this interesting because ASLR is specifically designed to make these locations unpredictable.

Instead of simply guessing the addresses, the exploitation chain obtains information about the actual memory layout.

This demonstrated how a memory disclosure stage can become a stepping stone toward something much more serious.

7. From memory disclosure to remote code execution

Now came the part I was particularly interested in: actually demonstrating command execution.

After the memory disclosure stages, the exploit proceeded to the final stage involving the manipulated HashTable structure.

The lab provided the following execution proof:

PROOF: uid=33(www-data) gid=33(www-data) groups=33(www-data)

And there it was.

The command had executed successfully under the www-data account, which is commonly used by web servers on Linux systems.

This confirmed that the exploitation chain had achieved remote code execution in the lab environment.

The next step was retrieving the flag.

The lab's exploit used the following command:

python3 exploit.py \ -u http://127.0.0.1:8088/index.php \ -c 'cat /f>/out/p1' \ --proof-file out/p1

The result returned the flag:

THM{b4ilout_l3aves_th3_h3ap_dang1ing}

THM{b4ilout_l3aves_th3_h3ap_dang1ing}

A pretty fitting flag for a vulnerability involving a bailout and a dangling pointer.

What made this practical exercise memorable for me was the fact that the target application itself never changed.

It continued to be a simple PHP page returning OK.

The exploitation happened because of the vulnerable runtime underneath it.

8. Detection and mitigation

Understanding how an attack works is one thing.

Knowing how to prevent or detect it is equally important.

Since PHP2Shell affects the PHP runtime, updating the application alone isn't enough.

The PHP installation itself needs to be patched.

The fixed releases identified in the security advisory are:

PHP branch	Fixed release
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Temporary risk reduction

If immediate patching isn't possible, administrators can review their PHP request-handling configuration and apply temporary defensive measures, such as restricting request-body sizes at the reverse proxy or web-server level.

Disabling session.upload_progress may also reduce exposure to the specific upload-progress attack path demonstrated in the lab:

session.upload_progress.enabled = 0

However, these measures are only temporary risk-reduction steps. They do not fix the underlying vulnerabilities and should not be considered complete mitigations.

The only safe solution is to update PHP to a fixed release.

After updating, restart PHP-FPM workers or reload/restart Apache when using mod_php.

If PHP runs inside containers, rebuild or replace the affected containers so that no vulnerable runtime instances remain.

What should defenders monitor?

Some suspicious indicators worth investigating include:

Unusually large PHPSESSID values in Set-Cookie response headers.
Suspicious multipart POST requests.
Unexpected PHP worker crashes.
Memory exhaustion errors.
PHP processes unexpectedly spawning shell processes.
Unusual command execution under the web server account.

One important lesson here is that monitoring only the application layer isn't sufficient.

Because the vulnerability is triggered during PHP's internal request processing, detection and prevention need to account for activity happening before the application script executes.

Patching the runtime remains the priority.

9. What I learned from this investigation

This was more than just another TryHackMe room for me.

It helped me connect several concepts that I had previously encountered separately.

Some of the things I explored included:

How PHP processes multipart/form-data requests.
What session.upload_progress actually does.
How memory allocation and dangling pointers work.
Why an out-of-memory bailout can become dangerous.
What ASLR does and why attackers try to bypass it.
How memory disclosure can assist remote code execution.
How PHP's internal cleanup mechanisms can become part of an exploitation chain.
Why securing the application doesn't necessarily secure the runtime.

But there's one thing that stood out above everything else.

Sometimes, the vulnerability isn't in the code you wrote. It's in the code your code depends on.

As someone learning cybersecurity alongside software development and AI/ML, I find these investigations particularly valuable.

I don't want to simply learn which command executes an exploit or how to retrieve a flag.

I want to understand what happens underneath, why a vulnerability exists, how it can be abused and, most importantly, how defenders can prevent it.

Because there's a difference between knowing that something works and understanding why it works.

And I'm genuinely enjoying the process of learning that difference.

Final thoughts

PHP2Shell was a great reminder that cybersecurity isn't just about finding vulnerabilities in websites.

It's also about understanding the technologies, runtimes, libraries and systems that make those websites work in the first place.

A seemingly harmless upload-progress feature, combined with a memory-management failure, demonstrated how something deep inside a runtime could eventually lead to remote code execution.

And that's what makes cybersecurity so interesting to me.

There's always another layer to investigate, another question to ask and another mechanism to understand.

Stay curious. Keep learning. Keep breaking things in controlled environments, and most importantly, understand what you're doing.

Disclaimer: This investigation was conducted in an authorized TryHackMe lab environment. The exploit and command-execution results described above relate to that controlled environment.

What SafeLine's PHP Core Rule Actually Watches in the Request

Mon, 26 Oct 2026 04:17:15 +0000

The PHP Core rule SafeLine shipped on 21 October is not a generic "block all uploads" switch. It is aimed at request features from the known chain behind CVE-2026-109618 and CVE-2026-109619.

Four signs are called out in the rule note. A request that carries PHP_SESSION_UPLOAD_PROGRESS. A PHPSESSID that fits the characteristic pattern. A content type of multipart/form-data. A body that combines abnormal form fields with suspicious content. Any one of those can appear in legitimate software. The rule is about the combination associated with the chain, which is why the first setting is observe, not drop.

That focus follows from CVE-2026-109618, which is about multipart parsing and memory state. Upload and form posts are the traffic you should be able to name in a log: time, source address, site, path, and the rule name PHPCoreRCECVE-2026-109618/109619. The write-up is at the rule discussion.

CVE-2026-109619 is the other half. Worker global state can linger between requests. The WAF rule will not print the worker's memory. It will tell you which HTTP client was sending the chain's request shape at the time a pool misbehaved. Use both logs.

Import the rule from the SafeLine rule library. Set the action to blacklist. Enable observe mode. Review a sample of hits against a known-good upload from your own application. If your application itself sends PHP_SESSION_UPLOAD_PROGRESS on a normal photo upload, you need that fact before you block, not after.

When the hits are probes rather than product traffic, move the rule to an intercept action and keep the event record for the follow-up on disk and credentials.

Does the rule fire on every multipart post?

It is built around the known chain's features, not every form on the internet.

What should a useful hit contain?

Time, source IP, site, path, and the rule name. Those are the fields worth capturing in the event view.

Can I skip observe mode if I trust the signature?

You can, but the published guidance is to observe first so a real upload path is not the thing you discover by outage.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

What to Inspect After a PHP Core Rule Hit

Mon, 26 Oct 2026 04:17:14 +0000

A SafeLine hit on the PHP Core rule is a starting point, not a closed case. CVE-2026-109618 and CVE-2026-109619 are serious because a crafted request can disturb the runtime or leave worker state behind. If the rule fires, or if the server looks wrong without a clean explanation, widen the search the same day.

Start with the event SafeLine already stored: attack time, source address, site, path, and the rule name. The 21 October rule is documented at the rule page. Match that minute to the web access log and the PHP error log. You are looking for the same client, the same path, and a runtime fault.

Then look at files. Check the web root, the upload directory, and the temporary directory PHP uses for multipart bodies. Look for PHP files that appeared or changed recently and that no deploy can explain. A new file next to an upload endpoint is more interesting than a hit with no file change, but both deserve a note.

Process and network checks come next. Unknown processes, unexpected outbound connections, and cron entries you did not add are reasons to treat the host as suspect. If that bar is met, rotate high-privilege accounts, database accounts, and API keys. Do not rotate everything on the first observe-mode hit from a scanner. Do rotate when logs and files agree that something landed.

Keep the rule in observe until you know your own upload traffic, then move it to block. Upgrade the PHP pool that served the hit. Restart that pool. Confirm the site still logs in and still accepts a normal file. The rule watches the chain. The upgrade removes the bug the chain is aimed at.

What is the minimum record to keep?

Time, source IP, site, path, rule name, and whether a file changed.

Should every hit trigger a credential rotation?

No. Rotate when logs or files show more than a probe.

Does blocking replace the PHP upgrade?

No. Blocking is a control at the proxy. The runtime still has to be patched.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

How to Inventory Every PHP Version Before You Call the Estate Patched

Mon, 26 Oct 2026 03:47:14 +0000

The failure mode in this PHP advisory is not "we upgraded PHP." It is "we upgraded one PHP and left three others running." CVE-2026-109618 and CVE-2026-109619 are in PHP Core, so every branch on the host is its own decision.

Build a table before you patch. Columns that earn their keep: site name, public host, PHP-FPM pool, binary path, version, owner, and status. Status should be one of upgraded, waiting, or cannot upgrade, with a reason in the last case. A shared server that still has an old pool for a forgotten landing page is still exposed.

Do the upgrade in a quiet window. Back up site files, the database, and the pool config first. After the package change, restart PHP or PHP-FPM and prove the new version with the same binary the pool uses, not with a php that happens to be first on a login shell.

Then test the paths that exercise the bugs: home page, login, upload, and a normal form post. Read the PHP error log for a new exception. Walk the process list and confirm no pool is still bound to the old build.

SafeLine does not replace that inventory. The 21 October rule gives you a place to watch suspicious multipart uploads while the list is incomplete. Set the action to blacklist, enable observe mode, and read hits instead of blocking the estate on hour one. The rule page is here.

When the inventory shows a site that cannot move yet, keep that host's rule in observe, restrict who can reach the origin, and do not treat the WAF note as a permanent patch.

How do I know which version a vhost uses?

Read the pool config and the binary that pool executes, not the default CLI PHP.

Can one SafeLine rule cover every old branch?

It can watch the request pattern. It does not upgrade the branch.

What belongs in the "cannot upgrade" note?

The business reason and the compensating control, such as observe mode plus a closed origin.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

Why Multipart Uploads Need a Separate Look After CVE-2026-109618

Mon, 26 Oct 2026 03:44:13 +0000

File upload is the practical entry for CVE-2026-109618. The weakness is in PHP's handling of multipart/form-data and the memory state around that parse, not in a single shopping-cart plugin.

An attacker does not need a valid image. They need a request that looks like a form upload and stresses the parser: odd boundaries, unexpected fields, or a progress token the application never meant to honor. The result called out in the advisory is service disruption or a runtime fault, which is enough to create a window for a follow-on web attack.

SafeLine's 21 October rule looks for that shape on the wire. The signals called out in the rule note are a PHP_SESSION_UPLOAD_PROGRESS parameter, a PHPSESSID that matches the known pattern, a multipart/form-data content type, and a body that pairs abnormal fields with suspicious content. Details are in the rule discussion.

Turn the rule action to blacklist and leave observe mode on. Observe mode writes the event and keeps the source and request. It does not drop the request. That matters on checkout, profile photo, and ticket-attachment routes, where a hard block on day one will page the wrong team.

While the rule watches, do the origin work. Back up files, the database, and the PHP pool config. Upgrade the PHP branch that pool actually uses. Restart PHP-FPM. Then click through home, login, upload, and form submit. Read the PHP error log for a new fault, and confirm no second vhost is still pinned to the old binary.

If the same address keeps changing the body of upload posts, treat that as probing even when the rule is still in observe. Only after that picture is stable should you switch the rule from record-only to block.

Is every upload form affected?

Any PHP path that accepts multipart bodies is in scope until that site's runtime is confirmed current.

Will observe mode stop the exploit?

No. It records. Blocking is a later, separate change.

What should be upgraded first?

The PHP version serving the upload vhost, not the CMS theme.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

BackBox's Kilter AI Keeps Humans in the Loop While Automating Network Fixes

Mon, 14 Sep 2026 14:00:00 +0000

As network vulnerabilities pile up faster than teams can patch them, most of the AI conversation in NetOps has centered on autonomy: letting AI agents make and execute changes on their own. BackBox is making a different bet. With the launch of its Kilter Platform — and Kilter AI, its new intelligence layer — the company is betting that NetSecOps teams want acceleration, not abdication.

We asked Irfahn Khimji, CISSP, Field CTO at BackBox, to walk through how that actually works in practice: what a human reviews before anything runs, where the hard limits are, and what claims about AI-driven network automation deserve some skepticism.

Walk me through the actual flow: a vulnerability shows up in the Enriched Data Aggregation layer, and a "CVE Workaround Chain" gets generated. What does that chain actually look like, and what specifically does a human review before anything executes?

When a vendor issues an advisory, it includes remediation or mitigation guidance — upgrade to a specific version, or change a configuration — and every vendor presents it differently. Kilter AI parses that advisory, normalizes it, and identifies what needs to happen to the device.

From there, the human-in-the-loop model requires a person to click a button before Kilter AI takes the next step: building the automation chain. Once built, that chain is tagged as AI-generated and still requires a human to review, verify, and approve it before it's scheduled to run.

Chains also enforce best practices by default. A common pattern wraps AI-generated automations in a Backup–Run Automation–Backup cycle, so the network can always be restored if something goes wrong. As Khimji put it, "The AI takes the coding out of the equation, but lets the human engineer decide whether to use it as-is or tweak it, and when to run it."

You describe Kilter AI as a "trusted advisor" rather than autonomous. Concretely, what decision has Kilter AI never been allowed to make on its own, even as trust builds over time? Where's the hard line?

Kilter AI is not allowed to take actions on customer networks, full stop. Its job is to aggregate data, generate recommendations, and surface insights — the research and development phase, not execution.

Why hold that line while competitors race toward full autonomy?

BackBox made a deliberate choice not to go fully autonomous, based directly on customer and prospect feedback. The sticking point is accountability: if an AI makes a mistake, the AI can't be held responsible for it — the person deploying it can. And accountability only works if the person carrying it has a very high level of confidence in the AI's output. "As an industry and society, we're not yet at the point where AI models are 100% or even 99% trustworthy," Khimji said. "Given that networks need more than 99% uptime, I'm not sure it's a risk worth taking just yet."

How much has the threat landscape actually accelerated?

Khimji pointed to a stack of external data supporting the urgency behind Kilter AI's design: over 49,000 CVEs published last year (a 20% increase over 2024, per NIST), with CVE.org projecting more than 60,000 by the end of 2026. The Global Incident Response Report 2026 found the fastest 25% of intrusions now reach exfiltration in 72 minutes, down from 285 minutes the year before. CrowdStrike's 2026 Global Threat Report logged an 89% year-over-year increase in attacks from AI-enabled adversaries, and IBM's X-Force Threat Intelligence Index flagged a 44% year-over-year increase in exploitation of public-facing applications, with 56% of disclosed vulnerabilities exploitable without authentication. IBM's Cost of a Data Breach Report also found that 97% of AI-related breaches trace back to inadequate guardrails.

Mythos, the AI-driven exploit generation approach Khimji referenced, is part of what's compressed attacker timelines from months or years down to days — one of the pressures BackBox says is driving demand for guardrails rather than full autonomy.

"Automation Creation Assistance" turns CLI input into production-ready automations without requiring scripting expertise. What happens when it gets that translation wrong? Is there a review step before it's saved or executed?

Every AI-created automation is tagged as such, and none of them can run without human approval. The underlying connect, authenticate, and disconnect commands are the same ones already used in BackBox's onboarding and inventory process — meaning they're proven, or the device wouldn't be in inventory in the first place.

The final required step is verifying the commands entered into the automation. If they came from the vulnerability intelligence service, they're pulled directly from the manufacturer's site. If they came from the automation creation assistant, the user typed them. Kilter AI's target users are network professionals — engineers, architects — who are assumed to know the CLI for their own devices, though a more junior analyst can cross-reference against vendor documentation.

You support 180+ vendors with 3,000+ pre-built automations. How much of that breadth is genuinely uniform versus vendor-specific quirks that still need manual tuning?

Not much of it is uniform. Every vendor has its own CLI dialect — a Cisco device takes "show run," while the equivalent on Fortinet is "show full-configuration." BackBox has spent more than 15 years building out that automation library manually, vendor command by vendor command.

For a NetSecOps team already drowning in tooling, what's the real integration lift? Does Kilter replace existing tools, or become one more thing to maintain?

It depends on where a team is starting from. Most prospects are either scripting manually with something like Python, using a vendor tool like Cisco's Catalyst Center, or handling the work by hand with no automation at all — and a smaller number do nothing and wait for the next hardware refresh.

For teams doing it manually, Kilter is new tooling, but the ROI has been steep: one customer cut its upgrade cycle for an entire switching infrastructure from six months to six days. For teams on vendor tools, Kilter typically replaces them — BackBox has displaced as many as five other tools in a single deployment, though one or two is more typical. Teams that have built their own scripting stack with staff who know both networking and coding are the toughest fit; if that describes an organization, Kilter probably isn't the upgrade.

What's a claim about AI-driven network automation — yours or a competitor's — that teams should be skeptical of right now?

Khimji singled out vendor platforms that push users to build AI agents natively on their own systems: "Users must learn to code on those platforms instead of in Python, etc., and those agents aren't portable outside those platforms." That lock-in, he argued, is worth questioning regardless of which vendor is offering it.

The bigger picture

Kilter AI is the intelligence layer inside BackBox's broader Kilter Platform, which also includes Kilter ALM (lifecycle management — onboarding, backup, recovery, upgrades, and patching across 180+ vendors) and Kilter Enterprise (compliance, policy, and configuration integrity). BackBox frames Kilter AI as the foundation for what it calls "agentic NetSecOps" — networks that reason, adapt, and act with increasing independence — but insists that autonomy will be earned one deliberate capability at a time, not declared on day one.

Irfahn Khimji is Field CTO at BackBox. Connect with him on LinkedIn.