What Is a WAF – and Why I Never Thought I'd Be Writing About It in 2026

I never thought that on 21 October 2026 I'd be writing about what a WAF is and why it matters. For twenty years it has been standard equipment for me. It's like the brakes on a car: they're not there because you drive badly, but because other people are on the road too.

Then came PHP2Shell. Two critical, CVSS 9.2 vulnerabilities in the PHP engine itself, exploitable without logging in – and exploitation attempts were seen before the fix was even published. Since then I've been working as a hotline. In two days, dozens of colleagues, clients and acquaintances asked me the same question: what do we do now?

This page grew out of those conversations. It isn't meant to be a textbook, but a way of sharing experience – like everything else on this site.

The Question That Started It All: Why Not Just Patch Right Away?

One of my colleagues put it very directly: "Why don't we just update? PHP has already released the new version, and the whole point is always to run the latest one."

He's right – halfway. Of course we have to update; there's no debate about that. The question is when and how.

In a production environment, especially in healthcare or financial services, a PHP update doesn't work like "the new version is out, so tomorrow it's live". Compatibility and dependencies have to be tested. It has to go through change management. A rollback has to be planned in case something doesn't work. That's days in a good case, and in a larger environment running many applications, it can be weeks.

Until then, something has to protect the system. That something is the WAF – together with the firewall and network segmentation.

What Is a WAF – in Plain Terms

A classic firewall looks at who wants to connect and where: which IP address, which port, which protocol. If port 443 is open to the website, the firewall lets the traffic through. What arrives through that open port, it no longer examines.

A WAF – web application firewall – starts exactly where the network firewall stops. It looks inside every single HTTP request and checks what the request is trying to do: which parameters it sends, how large its body is, how many files it uploads, whether its format is valid, and whether it resembles a known attack pattern.

A WAF can run in two modes:

• Detection mode: it only logs, it doesn't block. I always start new rules this way, to see what they would catch in production.
• Blocking mode: requests matching the rule are rejected, typically with a 403 error. Here the rule actually protects.

And there's a third thing many people forget: maintaining the rules. A WAF that was configured once and then nobody looked at for five years exists on paper, but in reality barely protects anything.

My Path: Since 2005, Never Without a WAF

Since 2005 I've been running IT infrastructure for healthcare providers in Hungary. In this sector we work with patient data, and a data leak here isn't an "inconvenience" – it means people's most sensitive data getting out.

I have never built a network without a firewall and a WAF. I have never exposed a single system, application or website to the internet without a properly configured WAF with well-developed rules standing in front of it.

What We've Seen Over the Past Two Days

This vulnerability isn't the first, and it won't be the last. Just as with OpenSSL, similar ones will keep coming. In a properly built environment, however, their risk can be reduced significantly with a firewall, a WAF and segmentation.

We tested it in several places: where the WAF I operate runs with the recommended settings, this vulnerability could not be exploited. We've been fine-tuning the rules everywhere since, because every application behaves a little differently – what's a harmless request in one place is suspicious in another.

Rules From My Own Knowledge Base

I've collected some patterns and rules from my own knowledge base, which I've built over more than 20 years. They aren't "magic rules"; they narrow the attack paths: multipart parsing, the session upload-progress feature, and oversized or deeply nested input.

1. ModSecurity (Apache / Nginx)

# Rule 1 – Block the session upload-progress field (CVE-2026-109619 path)
# Almost no applications use this field legitimately.
SecRule ARGS_NAMES "@rx (?i)^PHP_SESSION_UPLOAD_PROGRESS$" \
  "id:1026001,phase:2,deny,status:403,log,\
   msg:'PHP2Shell: session upload-progress field'"

# Rule 2 – Multipart only on upload endpoints (CVE-2026-109618 path)
SecRule REQUEST_HEADERS:Content-Type "@rx (?i)^multipart/form-data" \
  "id:1026002,phase:1,deny,status:403,log,chain,\
   msg:'PHP2Shell: multipart to non-upload endpoint'"
  SecRule REQUEST_FILENAME "!@rx ^/(upload|admin/media)/"

# Limits on field count, file count and nesting depth
SecRule &ARGS_POST "@gt 200" "id:1026003,phase:2,deny,status:403,log,msg:'PHP2Shell: too many POST fields'"
SecRule &FILES     "@gt 10"  "id:1026004,phase:2,deny,status:403,log,msg:'PHP2Shell: too many files'"
SecRule ARGS_NAMES "@rx (\[[^\]]*\]){8,}" \
  "id:1026005,phase:2,deny,status:403,log,msg:'PHP2Shell: deeply nested parameter'"

# Also keep malformed multipart blocked
SecRule MULTIPART_STRICT_ERROR "!@eq 0" "id:1026006,phase:2,deny,status:400,log,msg:'Malformed multipart'"
SecRequestBodyLimit 10485760

2. IIS (web.config, with the URL Rewrite module)

<system.webServer>
  <security>
    <requestFiltering>
      <requestLimits maxAllowedContentLength="10485760" maxQueryString="2048">
        <headerLimits>
          <add header="Content-Type" sizeLimit="256" />
          <add header="Cookie" sizeLimit="4096" />
        </headerLimits>
      </requestLimits>
    </requestFiltering>
  </security>
  <rewrite>
    <rules>
      <rule name="PHP2Shell - block multipart outside upload paths" stopProcessing="true">
        <match url=".*" />
        <conditions>
          <add input="{HTTP_CONTENT_TYPE}" pattern="^multipart/form-data" />
          <add input="{URL}" pattern="^/(upload|admin/media)/" negate="true" />
        </conditions>
        <action type="CustomResponse" statusCode="403" statusReason="Forbidden" />
      </rule>
    </rules>
  </rewrite>
</system.webServer>

On IIS, the request body can't be inspected for the upload-progress field, so turn the feature off in php.ini instead.

3. PHP configuration hardening (php.ini)

; Disable the upload-progress feature (CVE-2026-109619 path)
session.upload_progress.enabled = 0

; Low POST size – matched to what the application really needs
post_max_size = 10M

; PHP 8.5 only
fatal_error_backtraces = 0

The Logic Behind the Rules

• Multipart only where there really are uploads. A contact form or an API endpoint that accepts JSON has no need for multipart requests.
• Size limits everywhere. Request body, number of POST fields, number of files, parameter nesting depth – all matched to the application's real needs.
• Close a known attack path. The session upload-progress field is one proven path, and almost nobody uses it.
• Malformed format: reject immediately. An invalid multipart request has no business reaching the application.

A Temporarily Stricter WAF – and I Accept That Something Will Break

My experience with critical, actively exploited vulnerabilities is clear: for a limited period, a deliberately stricter WAF policy is the right call.

Yes, stricter rules may break a rarely used upload form or an unusually behaving plugin. That's an acceptable, temporary trade-off. A broken feature can be fixed in a few hours. A stolen customer database can't be recovered, and the reputational and regulatory consequences follow you for years.

Once every system has been updated and verified, the policy can be relaxed back to its normal baseline in a controlled way.

Penetration Testing and the MNB: Where a WAF Is a Baseline Requirement

Another important point: every production system has to be penetration tested, and a badly configured WAF shows up there immediately. True, most pentests hadn't spotted this particular flaw – but that's exactly why layered defence is needed. A pentest is a snapshot; a WAF looks at every request.

I worked in information security in the banking sector, and there a WAF was always a baseline requirement. The MNB (the Central Bank of Hungary) regularly inspects banks and treats it as a supervisory expectation that every internet-facing service sits behind a WAF.

I See It Every Day: The Internet Is Full of Systems Without a WAF

Outside the world of banks, however, the picture is completely different. Every day I see web applications, websites, customer portals and APIs with no WAF in front of them at all. And every day I meet IT operations colleagues who simply skip the security part: the system "works", so it's done.

In my view, this is primarily not the fault of individual operators, but of companies. Many companies hire the wrong specialists and the wrong IT operators because it's cheaper, or because "nothing has gone wrong so far". And then the obvious question is: where is the information security officer, where is the CISO? Who checks whether what's been put on the internet is actually protected?

Cloud and SaaS: Cheaper – and Often Unprotected

A great many cloud and SaaS services aren't behind a WAF, simply because it's cheaper that way. Meanwhile, every day all of us use more and more of them – often without knowing what's behind them:

• accounting and invoicing software, online payroll and HR portals;
• healthcare systems: appointment booking, lab result portals, private clinic customer portals;
• web shops and the payment, order management and warehouse systems behind them;
• booking systems: hotels, restaurants, gyms, beauty salons;
• property and condominium management portals, holding residents' data and payments;
• school, nursery and sports club systems, with children's data;
• CRM, ticketing and customer service systems, partner portals and document-sharing platforms;
• the web backends of fleet management, telematics and smart home apps.

Every one of these holds personal, financial or health data. And most users – even most business leaders – don't know whether the service they use runs behind a WAF, whether it's kept up to date, and what happens when a flaw like PHP2Shell comes along.

What every business leader and company using SaaS and IT services should watch out for – and why BCDR is my first question in every situation like this – I've written up in detail on a separate page about BCDR and IT operations.

Practical Tips

• Don't put anything on the internet without a WAF. Not a website, not an API, not a "temporary" test system.
• Start in detection mode, then switch to blocking. A day or two of logs tells you a lot about the application's real traffic.
• Give the rules an owner. Someone who looks at them regularly, tunes them, and knows why each rule is there.
• Tighten temporarily during a critical vulnerability. The inconvenience is temporary; data loss is permanent.
• A WAF is no excuse to postpone patching. It buys time, but the PHP engine still has to be updated – tested, with a rollback plan.

If you'd like us to review your WAF and firewall configuration, or you need a risk assessment or GRC review, get in touch on the contact page or via CSE Business.

Related Pages

• PHP2Shell vulnerability (CVE-2026-109618, CVE-2026-109619) – what it means and how to reduce the risk
• PHP2Shell risk handbook – what the vulnerability means by website type
• BCDR and IT operations – "Csaba, what should we do?" "Show me the BCDR!"
• Autosecurit / Skyguard complete outage – when there's no business continuity plan
• Three backups, one point of failure – what a 4 a.m. outage teaches