A firewall rule opened a VPN path to 50 million immigration records, in an account of the early 2010s

One retelling, more than a decade old, naming nobody

Every fact in this story comes from one place: The Register's column of 24 September 2026, which retells a former security officer's memory of the early 2010s. Taking that to mean 2010 to 2013, the events sit roughly 13 to 17 years before publication (our arithmetic: 12.7 years from the end of 2013 and 16.7 years from the start of 2010). The account names no government, no contractor, no datacenter operator and no programme.

It is also not the kind of exposure the headline may bring to mind. No credential, repository, API or storage location is described as exposed. What changed was a firewall rule, and what the rule created was a network path: from a VPN that thousands of people could use, through development servers, towards a classified server that held about 50 million records about immigration. A path is not a breach. Nobody in the account is said to have read, copied or altered a record.

What the account does not establish is the more useful part. It does not say how long the rule stood, whether anyone other than the researcher used the path, or whether logs were ever checked. It does not say how many records the rule made reachable, only how many the server held. And it rests on one person's recollection, with no government or contractor statement beside it.

What the account says happened

The Register describes Joe Brinkley as a security researcher who previously worked for a government contractor as an information system security officer, responsible for firewall rule changes plus network intrusion detection and prevention. His story, as retold, runs in five steps.

1. The setup. The contractor's developers tested new code in a low-security commercial datacenter and ran production in a classified one. There was always a hard firewall between them, and developers used a provisioning server to help deploy code from development to production.
2. The request. The developers wanted that provisioning server to reach all the production servers in the classified datacenter, to make pushing code easier. The VPN into the commercial datacenter was provided by the datacenter itself, not the government, and other non-government tenants had servers reachable through the same connection.
3. The objection. Brinkley told the Change Review Board it was a very bad idea.
4. The approval. In a week when he was on vacation, the developers "talked directly to the Change Acceptance Board and got the rule changed."
5. The demonstration and the reversal. When he returned, he sat a member of his company and a government representative down, tethered his laptop to his phone, and logged into the dev server over the VPN. He then showed that the same connection could get him into the production server and control it. After he showed supervisors, they "immediately changed the rule back".

The account uses two board names, Change Review Board and Change Acceptance Board, and does not say whether they are the same body or whether the government representative sat on either.

How a contractor's convenience becomes the data owner's exposure

Read as a supply chain story, the interesting fact is where the boundary sat. The government's data lived in a classified datacenter. The contractor's development work lived in a commercial one, reached over a VPN the datacenter operator ran and other tenants also used. The rule that mattered joined the two. It was proposed by the contractor's developers and approved by a change board that, in this account, acted while the security officer was away. The account says a government representative attended the demonstration. It does not say the government saw or approved the rule before that.

The Register's headline says the contractor "exposed" a path. On this account, the more precise reading is that a change board accepted a rule that created one, and the security officer found it.

That is the structural weakness of delivery pipelines run by third parties, and it needs no stolen secret. Something built for the convenience of the people who deploy a system, a provisioning server that can reach every production machine, becomes a permanent property of the data owner's network the moment the rule is accepted. Three features made it worse here, all as recounted:

• A shared low-trust side. Thousands of people could use the VPN, and other tenants' servers were reachable through the same connection.
• A single approval that could proceed without the reviewer who objected. The account does not say whether a deputy existed.
• An ambiguous scope. The developers asked for the provisioning server to reach production. Brinkley's objection, as quoted, speaks of "anybody" in the low-level datacenter. The account does not say whether the rule named one host or a range. That matters, because a rule written for one host is a rule for everyone who can become that host.

Four comforting words

The friendly-name fallacy is the habit of mistaking the name of a control for the control. This account is full of names that sounded protective.

Comforting labels in the account and what each meant, as retold by The Register on 24 September 2026

Label	What it meant here
VPN	A network run by the commercial datacenter and open to thousands of users, with other tenants' servers reachable through the same connection. It was access, not privacy.
Hard firewall	A rule set that a change board could edit in a week the security officer was away. A rule set is a policy someone can change, not a wall.
Development	A stepping stone. From a login to the dev server, the demonstration went on to show a route into production.
Password protected	The last barrier: a username and password, with no multi-factor authentication and low password standards at the time.

Nothing in the account is described as read-only, and the demonstration reportedly included controlling the machine, so the read-only fallacy does not apply here. Its nearest cousin does: "it is only the dev environment". In our view, a development system with a route to production is a production system with a different name.

What the researcher did, and did not do

What he did, as told. He objected in the review process. When the rule was approved without him, the account has him arranging, on his return, a demonstration for a colleague from his own company and a government representative, so that both saw the path for themselves. He tethered his laptop to his phone, which we read as an attempt to come in from outside the contractor's own network, the vantage a stranger would have (our inference, not stated). He logged into the dev server over the VPN, turned "the box" on and off, and showed the same connection could reach and control a production server.

What the account does not say he did. It does not say he read, copied or altered any record. It does not say which machine he turned off and on: the sentence follows the dev server login, and we do not assume it was production. It does not say whether the demonstration was agreed in advance, or what safeguards surrounded a live test near a system holding 50 million records. Nor does it describe any public disclosure at the time. It describes only an internal route: a demonstration to a colleague and a government representative, then a reversal. The public telling came years later, in a column that invites readers to send in their own stories.

This is a description of method, not a criticism of the researcher. It is a reminder that proving a path in front of the people who own the risk is worth more than an argument in a meeting, and that the proof itself needs a scope and a window agreed in writing.

When the network gives nothing, the password does everything

The account is plain about what was left: the servers still required a username and password, there was no multi-factor authentication, and password standards were low at the time. The Register adds, in its own voice, that an enterprising hacker could have tried guessing or brute-forcing the combinations. That is the Register's inference about what might have followed, not something anyone is reported to have done.

For a defender, this is where secret scanning, multi-factor authentication and fast revocation belong: as the layer that must hold when a route already exists, not as the first line of defence. Contractor engagements strain it. Access details for delivery pipelines commonly end up in tickets, wikis and chat, and they can outlive the engagement or the person. None of that is in the account. It is the general reason to treat the credential layer as if the network layer might already have failed.

What the account does and does not establish

Claims in The Register's retelling of Joe Brinkley's account, checked against what it says and what it leaves out

Question	Stated in the account	Not stated
Who	A government contractor, a classified datacenter, a commercial datacenter that provided the VPN.	Which government, contractor, datacenter operator or programme.
What was exposed	A firewall rule letting a provisioning server reach production servers; a server with about 50 million records about immigration.	Any credential, repository, API or storage location. How many records the rule made reachable.
When	The early 2010s. The rule was changed in one week when the researcher was on vacation.	Dates, or how many days the rule stood before it was reversed.
Use by others	The researcher demonstrated the path. The change potentially made production reachable from a network open to thousands.	Any use by anyone else, any log review, any statement that no one else used it.
Authentication	A username and password were still required. No multi-factor authentication. Low password standards.	How the researcher authenticated to production, or whether guessing was ever tried.
Fix	Supervisors immediately changed the rule back after the demonstration.	Any later change to the review process, the VPN arrangement or the password standards.
Confirmation	One former security officer, retold by one publication.	Any statement from a government, a contractor or the datacenter operator.

In our reading, the account is specific enough to be credible on mechanism and silent on the facts that would tell a defender whether harm followed. Treat it as a design failure that was caught, not as a breach that was measured.

What to do, in the order worth doing it

The UK NCSC's guidance on preventing lateral movement (published 2018, reviewed March 2021) says systems and data that do not need to interact should be separated into different network segments, with users allowed into a segment only where needed. Its supply chain security guidance (reviewed October 2025) sets out 12 principles for controlling and overseeing suppliers. Neither is about this incident. Both describe the controls it lacked.

Method and interest

This is a recounted incident, not a disclosure with a case number. The Register's PWNED column collects stories of how security becomes self-owned and invites readers to submit their own, so the format rewards a vivid mechanism and a moral. Brinkley's profile on a security training site describes him as a pentester, mentor and speaker, so a memorable story may carry some reputational value for him, as any conference anecdote can. Neither point is an accusation. They are reasons to hold the detail loosely and to weigh the account on what a defender can test in their own network, rather than on the vividness of the tale. We found no independent corroboration, and we make no claim about it either way.

The question that exposes the gap

If your head of security were on holiday next week, which of your firewall rules between a contractor's network and your most sensitive data could change without anyone in security seeing it before it took effect?

If the honest answer is that you would find out from a demonstration, your design is the one in this story.

Key facts