---
title: "I Said It Was Behind a Firewall. Nobody Had Written Down When We Checked."
canonical: https://dxdev.com/blog/undated-assumption-staff-wiki-firewall/
datePublished: 2026-10-21
---
An old staff wiki, MediaWiki 1.15 on PHP 5.3 under IIS on a partner-hosted box, was open to the internet, and I told the agent that flagged it that it was wrong.

The lane manager agent raised it at 11:56 am on 10/21/26. At 11:57 I said the wiki was already behind an IP firewall and the agent should test properly. I was the one who was wrong.

## What the morning looked like

Two PHP CVEs were in the news. An agent research pass had confirmed the bug itself but not the "70 percent of sites" figure that was going around. If you are running older PHP and want a second set of eyes on your exposure, [we can help with PHP2Shell](/php2shell/).

I had a settled picture of the wiki: behind an IP firewall. I had no date on that picture and no record of how I knew it. It was an assumption, and when the agent said "open to the internet," I treated my assumption as the stronger evidence.

## The wrong turn

The agent did what I told it to and retested from my own PC. My PC is on the allowlist.

At 11:59 am it got a 200, retracted its flag, and wrote IP-restricted into the surface-map page. Its later self-review was blunt: my 200 proved nothing, because exposure tests run from outside the allowlist.

For about two hours the surface map carried a row saying the wiki was restricted, and the only thing behind it was one 200 from a machine that is on the allowlist.

## How the correction happened

At 1:58 pm the next lane manager checked from 10 outside check-host nodes. Nine returned 200 with the login page rendering, and the TLS cert had expired. It rejected the earlier conclusion and filed a ticket with two options: allowlist it or retire it. At 2:02 pm the surface-map row was corrected to "Publicly reachable from outside."

At 3:12 pm, 12 outside nodes returned 200.

At 3:16 pm I told the agent I had been calm because I assumed I was behind an IP firewall, and that I was wrong. At 3:17 pm I said take it offline.

## The takedown

At 3:25 pm the site and app pool were stopped and auto-start was turned off, with a config backup taken first. The same 12 outside nodes then returned 404.

This is not a we-were-hacked post. The takedown was precautionary, because the software is years past end of life, the cert had expired, and the page was rendering a login form to the open internet.

## What an undated row costs

An exposure fact needs a date and the method that verified it. "IP-restricted" with neither is an assertion, and a method that ran from inside the allowlist produces a 200 that looks like evidence. A fact without both counts as unknown, and I have to test it from outside the allowlist.

## Still open

- A firewall block on the host.
- Repointing the staff links to the new KB.
- The retire-or-keep decision on the wiki.
- A wider audit of the other old surfaces.

The row written at 11:59 am said IP-restricted on the strength of a single 200 from my PC, with no date and no method. The row that replaced it says "Publicly reachable from outside," with the date and the check that showed it.