RC RANDOM CHAOS

Bitsight found 6,000 unauthenticated fuel gauges online

6,000 Automatic Tank Gauges are exposed to the internet with no authentication. The protocol, the owners, and why the fix isn't technical.

· 7 min read

The scan that should embarrass an industry

In January 2024, a Bitsight scan of the public IPv4 space found roughly 6,000 Automatic Tank Gauges (ATGs) reachable on TCP port 10001 with no authentication. These are the devices that sit on top of underground fuel tanks at gas stations, airports, military bases, and hospitals. They measure how much fuel is in the tank, whether the tank is leaking, and at what temperature the product is stored. Anyone with a laptop and an internet connection could query them, read the data, and in many cases send commands back.

This is not a zero-day. The Veeder-Root TLS-350 and similar gauges have been shipping with the same TCP/IP serial bridge since the late 1990s. The protocol, sometimes called the “Veeder-Root Serial Interface,” is documented in vendor PDFs you can find on Google. Rapid7 wrote about it in 2015. CISA issued advisory ICSA-15-029-01 the same year. Nine years later, the exposed count is still in the thousands.

That gap - known vulnerability, public advisory, no behavioral change - is the actual story. The tank gauges are a symptom. The systemic issue is how operational technology gets connected to the internet, who owns the risk, and why nobody is forced to clean it up.

What an ATG actually does

An Automatic Tank Gauge is a small industrial computer wired to probes inside fuel tanks. It tracks inventory in gallons, water intrusion in inches, and temperature in degrees. It reports those numbers to the station owner, the fuel supplier, and often to a regulator - the EPA requires leak detection on underground storage tanks under 40 CFR 280, and ATGs are the standard way to meet that requirement.

The device has a serial port. To let a corporate office or a fuel supplier read inventory remotely, station operators bolt a serial-to-Ethernet adapter onto it, plug it into the station router, and forward port 10001 from the public IP to the gauge. That’s the entire “deployment.” There is no authentication step in the Veeder-Root protocol. The assumption baked into the design is that the serial line is physically inside a locked equipment room. Once you bridge serial to TCP and expose it to the internet, that assumption is gone, and nothing in the device replaces it.

Send the command I20100 and the gauge returns inventory. Send S60200 and you can change the tank’s configured high-product alarm threshold. Send S00200 and you can shut down the gauge’s reporting. Some firmware versions accept commands that force the relay outputs to switch state - which on certain station layouts controls the submersible pump or the leak alarm horn.

What an attacker can actually do

The realistic harm ladder, in order of plausibility:

First, surveillance. Reading inventory across 6,000 stations gives you a real-time map of fuel supply. That’s commercially valuable to commodity traders and operationally valuable to anyone planning logistics during a disruption. There is no detection on the device side - the gauge does not log who queried it.

Second, denial. Reconfiguring the gauge’s alarm thresholds, or simply spamming it with malformed commands until the serial bridge falls over, takes the station’s leak detection offline. The station is now out of EPA compliance. If the operator doesn’t notice within 30 days, they’re subject to enforcement action regardless of whether a leak actually occurred.

Third, masking. An attacker who wanted to cover up an actual fuel theft or an actual leak could rewrite the inventory totals or suppress the alarm. This is the scenario that gets cited in threat briefings, and it is the least likely to happen at scale because it requires someone to also be physically present at the station. It is, however, exactly the scenario a state actor running a disruption campaign against fuel logistics would care about.

Fourth, pivot. The serial-to-Ethernet adapter is on the same flat network as the point-of-sale system, the CCTV DVR, and the back-office PC. Compromising the gauge is rarely the end goal - it’s a foothold on a network that processes credit cards.

None of this requires custom malware. The tooling exists. Shodan indexes the devices. The protocol is text-based. A competent undergraduate can write the client in an afternoon.

Why this keeps not getting fixed

The gauges are owned by station operators. The operators are usually franchisees - independent small businesses running a branded forecourt under a supply contract with a major. The major doesn’t own the gauge. The brand doesn’t own the gauge. The point-of-sale vendor doesn’t own the gauge. The serial-to-Ethernet adapter was installed by a local technician who left the company in 2011.

When Bitsight or Rapid7 publishes a list of exposed IPs, there is no single party with the authority and the contact information to fix them. CISA can issue an advisory. The advisory lands on the desks of corporate security teams at the majors, who pass it to their franchise compliance group, who send a PDF to franchisees, who file it. The technician who would actually log into the station router does not read CISA bulletins.

This is the same structure that left thousands of building management systems, water utility HMIs, and solar inverters exposed for the last decade. The asset is critical. The owner is fragmented. The vendor’s threat model assumed an air gap. The integrator who broke the air gap is long gone. Nobody currently on payroll has both the access and the mandate to close the port.

What actually works

Three interventions have moved the exposed count down in similar fleets. None of them are technically interesting.

One, the ISP closes the port. When a residential or small-business ISP starts blocking inbound TCP 10001 by default, the exposure drops overnight without any action by the station operator. Comcast did this for inbound SMB after WannaCry. It works because it removes the customer from the decision loop. The downside is that legitimate remote-monitoring contracts break, and the ISP eats the support calls.

Two, the fuel supplier mandates a VPN. Some majors now require franchisees to use a managed network appliance that tunnels gauge traffic to the supplier’s cloud, with the public port closed. This is enforced through the supply contract, which is the only lever that reliably reaches a franchisee. It works when the major treats it as a compliance line item and audits for it. It doesn’t work when the major treats it as a recommendation.

Three, the regulator names the control. The EPA’s leak detection rule mandates that ATGs function correctly. It does not currently mandate that they be protected from remote tampering. A one-line amendment requiring that ATG network interfaces not be reachable from the public internet would push the cleanup onto the same compliance cadence that the operator is already running. State environmental agencies have used similar language for tank integrity testing for years.

The technical fix on the device - adding authentication to the serial protocol - is the least useful intervention. The installed base is too old, the firmware update path goes through the same fragmented owner chain, and even if Veeder-Root shipped a patched version tomorrow, the median ATG in the field will not see it for a decade.

What this tells you about the rest of OT

The ATG fleet is a clean read on how industrial control systems actually sit on the internet. The same pattern shows up in:

  • Building automation. BACnet on UDP 47808, ~20,000 devices indexed by Shodan as of late 2025, mostly Tridium Niagara controllers running HVAC and lighting in commercial buildings.
  • Water and wastewater. Modbus on TCP 502, Allen-Bradley CIP on TCP 44818, several thousand small-utility PLCs that should not have public IPs at all.
  • Solar. SunSpec inverters with web interfaces that ship with default credentials and run on residential connections, aggregated into virtual power plants the homeowner doesn’t know exist.

In each case the protocol predates the public internet, the vendor’s threat model assumes physical isolation, the integrator made a pragmatic choice ten years ago, and nobody currently on payroll owns the resulting exposure.

If you run security at an organization that owns any of this, the action is not to buy an OT monitoring product. The action is to produce a list of every device you own that speaks an industrial protocol, identify which ones have a public IP or a port forward, and put a name next to each one - a person who has both the access to change the configuration and the authority to do it without asking three layers up. If the list is empty next to any device, that device is going to show up in the next Bitsight scan, and you will read about it in a news article before you read about it from your own team.

The 6,000 tank gauges are not the problem. The unanswered ownership question behind them is.

Share

Keep Reading

Stay in the loop

New writing delivered when it's ready. No schedule, no spam.