Telstra 5G modem wifi: VN Commodore-level security

In this post, I share my discovery of a vulnerability in the Telstra 5G Modem that allows attackers to compromise Wi-Fi passwords in seconds using the Pixie Dust attack, and why it reminds me of the VN Commodore flaw that let thieves steal cars with a screwdriver and barely any damage. I also walk through the responsible disclosure process and where things stand today.

A car you can steal with a screwdriver?

Imagine it is the late 90s, and you're with your family in an inner suburb of Brisbane. It was a typically humid Queensland evening - the kind where you either sit inside in the aircon or go outside and basically melt. We were watching TV and relaxing when suddenly there was a faint noise - nothing alarming, just a subtle sound that barely registered. Less than a minute later, my brother's VN Commodore started and drove away - we caught a glimpse of the thieves as they left, and that was it.

A few days later the police called to say they'd found the abandoned car, and we finally saw how they'd done it. The VN Holden Commodore had a design flaw that made it almost comically easy to steal. Thieves discovered that by entering through the boot (the lock was poorly supported and easy to push in), climbing inside, popping off the air-conditioning knob, and turning it into a makeshift key, they could start the car with nothing more than a screwdriver. No hotwiring, no sophisticated tools - just a plastic knob and basic hand tools. All that was damaged was the boot lock, and it was easily refitted or replaced. It was so stupidly simple that it was almost insulting. You didn't need a lot of skill - just knowledge of the flaw and the confidence to exploit it quickly.

This same pattern is what I discovered in the Telstra 5G Modem. This time, instead of a screwdriver and a plastic knob, it was a Raspberry Pi with a USB Wi-Fi dongle. And instead of stealing a car, attackers can quietly steal your entire Wi-Fi network in seconds.

Pwning the Arcadyan Meteor2 Wi-Fi in seconds

Understanding the Vulnerability: WPS and the Pixie Dust Attack

Wi-Fi Protected Setup (WPS) was designed for convenience - instead of typing in a long password, you push a button or enter an 8-digit PIN, and everything just connects. It's the "I don't want to read the manual" feature baked into a lot of home routers.

The problem is that the PIN-based mechanism behind WPS has a much smaller effective keyspace than a proper Wi-Fi password. Security researchers have known for years that this opens the door to attacks that simply brute-force the PIN instead of the real password.

The Pixie Dust attack is an offline brute-force attack that can recover the WPS PIN - and through that, the actual Wi-Fi password - even if that password is a strong, randomly generated 16-character string, as is the case in the Telstra 5G Modem. Once you've captured the WPS handshake, the hard work happens offline, in seconds, not days.

As you can see in the diagram - once Wifite determines we have an open WPS feature, it runs a brief preamble and captures the Diffie-Hellman keys and Nonces. With those, we can exploit the weak Pseudo Random Number Generator (PRNG) to calculate the WPS PIN offline, as it is (typically) only 8 digits. Once we have the PIN, it's trivial to get the Wi-Fi password.

Technical Details of the Affected Modem

The vulnerable device is the Telstra 5G Modem 2, also known as the Arcadyan Meteor2. Here are the specific details from the device I tested:

• Model name: Meteor2
• Firmware version: 0.02.07r
• Hardware version: XCV56AX447M-F100-TA

The vulnerability exists in the default configuration. WPS is enabled by default on factory-configured devices, and the issue persists even after a factory reset. This confirms it's a vulnerability in the firmware, not a misconfiguration.

Attack Methodology

To actually pull this off, the shopping list is:

• A computer (e.g., Raspberry Pi) capable of running a penetration-testing OS like Kali Linux
• A Wi-Fi adapter that supports monitor mode (I used an EDUP EP-AX1672 AX3000 with the mt7921au chipset)
• Tools like Wifite2 to automate WPS attacks (though you can also do it manually; when learning pentesting this is a good idea)
• Be within range of the Telstra 5G Modem 2

In my testing, I recovered the 16-character Wi-Fi password in less than 10 seconds in one successful run (see video above). Another attempt took around 45 seconds. Sometimes it fails and you rerun it, but we're talking seconds to minutes, not hours - this isn't a sophisticated attack - it's "press go and finish your sip of coffee" levels of effort.

Impact Assessment

This vulnerability falls under the category of Broken Authentication and Session Management, specifically an Authentication Bypass. In practical terms, it's a critical (P1) severity issue. The attack requires physical proximity - the attacker must be within Wi-Fi range. But in dense urban environments, that's not much of a limitation. Someone parked on the street, in a neighbouring apartment, or even in a nearby building could potentially gain access.

Once an attacker has your Wi-Fi password, they have complete access to your network. They can intercept unencrypted traffic, access internal services and devices (NAS drives, printers, IoT devices), and potentially pivot further into your home or small business network. The barrier is low: free tools, cheap hardware, and a minute of access.

Responsible Disclosure Journey

I discovered this vulnerability in April 2025 and reported it through Telstra's Vulnerability Disclosure Program via Bugcrowd. Initially, the submission was marked as "Not Applicable" because the device was considered out of scope for the program. After further review and internal discussion, Telstra's security team decided to review the submission anyway, and the people I was put in contact with were friendly and helpful.

Current Reality: Mitigated, But Not Actually Fixed.

To my surprise, the firmware version on my device remains unchanged (as of January 2026). It's still running the vulnerable version 0.02.07r. Instead of deploying a patched firmware, Telstra has taken a different approach (which I recommended in my BugCrowd report as a potential mitigation): they've remotely disabled the WPS feature on customer devices.

The device vendor (Arcadyan) presumably acknowledged the issue. The information passed back to me was that the vulnerability existed in the firmware version I tested (0.02.07r), but my understanding is that they claimed it had already been resolved in an upcoming firmware release. The communication indicated that, subject to successful testing, a firmware update was expected to roll out around August 2025.

UPDATE: The new rollout date for the firmware update is now later in 2026.

This mitigates the risk for Telstra customers - the immediate attack surface is removed, but it's a configuration workaround, not a code-level fix. The underlying firmware flaw is still present; it's like Telstra removed the boot lock, but the air-con knob is still there to start the car without a key.

This becomes even more concerning when you consider the wider ecosystem. The same Arcadyan Meteor2 hardware is used by other ISPs around the world - if those providers are running the same or similar firmware and still have WPS enabled by default, their customers may still be fully vulnerable to the same Pixie Dust attack. Telstra has disabled WPS for their customers, but what about everyone else?

Recommendations

For ISPs and Operators

Don't stop at configuration-only mitigations. Push Arcadyan to ship and certify a truly fixed firmware for the Meteor2 platform, and roll it out across all deployed devices. There's a reason why vulnerability testers typically give vendors a 90-day window to fix vulnerabilities; configuration changes are a band-aid; firmware fixes are the real solution.

Audit other router models in your portfolio for WPS being enabled by default and known WPS vulnerabilities. This isn't just about this one device - it's about understanding the security posture of your entire product line.

For Device Vendors

Treat WPS vulnerabilities as product-level flaws, not just configuration issues. When you claim a fix exists, make sure it's actually shipped ASAP and visible as a new firmware version. Coordinate with ISPs so they can deploy it quickly and verify it's active in the field.

For End Users

Who actually uses the WPS feature on their router? I'm guessing not many people. It's typically a comically tiny button on the router's back panel that is easily missed, and in the case of the Telstra 5G Modem, there isn't even a button, so the end user has no way of accessing it.

Log into your router's admin interface and check: Is WPS enabled? If so, disable it immediately. What firmware version are you running? Keep an eye out for updates. Confirm that WPS is indeed disabled.

From Dashboard Knobs to Wi-Fi Dongles

The VN Commodore looked secure from the outside. It had all the normal security features, yet a simple combination of screwdriver, plastic knob, and design oversight made it trivial to steal. The car itself wasn't the problem - it was the design choices that made basic tools so powerful.

Today, a Raspberry Pi with a USB Wi-Fi dongle and tools like Wifite2 are the digital equivalents of that screwdriver and knob. In both cases, the real problem isn't the tool - it's the design choices that make those tools so effective against everyday systems.

We can't always control design flaws, but we can control how we respond to them. Users need to take responsibility for securing their own equipment: check configurations, disable risky features like WPS, and push providers to deliver real, firmware-level fixes. Don't assume someone else has taken care of it.

If a screwdriver can steal a car and a $50 hacking kit can steal your Wi-Fi, then security needs to be something you actively verify, not something you simply assume. The VN Commodore taught me that lesson years ago - a weak boot lock and a plastic air-con knob turned a basic tool into a car thief's shortcut. The Telstra 5G Modem is the modern version of that story: a weak WPS implementation and WPS left enabled (despite no physical button) keeps the barrier to attack low. Users should lock down WPS and keep firmware current, while vendors and ISPs should ship real fixes, not just configuration workarounds.