A Worm Hid Payloads Too Big to Scan in 42 GitHub Repos — Would You Know Which of Your Devices Pulled One?

Security researchers just documented a worm that compromised 42 GitHub repositories by hiding its payload inside blobs measuring 12.9 to 13.7 MB — deliberately oversized, because GitHub code search stops indexing well below that size. Every search, every audit, every casual diff review came back clean. The malware simply lived in the part of the repository where the tooling stops looking.

Here's the thing: this is not just a GitHub problem or a developer problem. That code gets cloned and pulled onto machines sitting on your network. Developer workstations. Build servers. A staging box nobody has touched since 2023. A Raspberry Pi under a desk running someone's side project. When an incident like this breaks, the question that lands on your desk within the hour is simple and brutal:

"Which of our devices pulled from those repos?"

If your answer starts with "let me check" and ends with three hours of grepping DHCP logs and SSHing into switches to read MAC tables, you have a network visibility problem — and no endpoint agent will fix it.

The Problem: Your Inventory Ends Where Your Agents End

Ask a room of sysadmins what devices are on their network and you'll get a confident answer. Ask them to prove it right now — with a live list, not the spreadsheet from the last audit, not the Visio diagram from 2021 — and the room goes quiet.

That gap is exactly where incidents like this worm do their damage:

Your RMM only knows about managed endpoints. NinjaOne, ConnectWise, Datto — pick your platform — it sees machines with agents installed. It has no idea about the contractor laptop that joined the guest VLAN last Tuesday, the IP cameras someone installed without a ticket, or the test server an intern spun up on a spare switch port.

Your standalone network monitor only knows about devices it was told to poll. Tools like PRTG or LibreNMS will happily graph the 47 switches and firewalls you manually added. They won't tell you that device #48 appeared on switch 3, port 14 yesterday afternoon.

Your helpdesk has no device context. When a user reports "the shared drive is slow," the ticket doesn't know what switch they're patched into, what machine they're on, or whether that machine has ever been seen on your network before.

And GitHub, npm, and pip know nothing about any of it. The supply chain delivers code straight to endpoints, bypassing every layer of your stack.

So when a worm poisons 42 repos and the news breaks, the real-world workflow looks like this:

1. 09:15 — CIO forwards the article: "Are we exposed?"
2. 09:20 — You export the agent list from the RMM. 312 machines. Fine.
3. 10:00 — You SSH into a dozen switches one at a time, dumping MAC address tables to cross-reference.
4. 11:30 — You pull DHCP leases from two Windows DHCP servers and a firewall that does its own DHCP for the guest network.
5. 13:00 — You're still reconciling three lists that don't agree, and nobody has even checked whether the build servers have the affected packages installed.

Half a day, minimum, before you can start answering the actual question. Every hour you spend manually building an inventory is an hour the response window stays open — SLA clocks running, users filing duplicate tickets, and the tech who drew the short straw burning out a little more.

The worst part? The answer goes stale the moment a new device joins the network. Next incident, you do it all again.

Why does this keep happening? Siloed architecture. RMM platforms grew up around managed endpoints. Standalone network monitors grew up around SNMP polling of infrastructure. Helpdesks grew up around tickets. Each silo made sense on its own — and together they leave exactly the gap that matters: nobody owns the question "what is actually on this network, right now?"

How AlertMonitor Closes the Gap

AlertMonitor was built on a simple premise: your map of the network should be as current as the network itself.

Continuous discovery, not quarterly sweeps. AlertMonitor discovers every device on the network — switches, firewalls, access points, printers, IP cameras, servers, and unmanaged endpoints — using SNMP, ARP, and active scanning. Continuously, not when someone remembers to run an audit.

The live topology map reflects reality. When a new device appears, an alert fires immediately with full network context: which switch, which port, which VLAN, and what the MAC vendor suggests the device is. When a switch drops offline or a link goes down, you know in seconds — not when the first user calls.

Discovery ties into the rest of the platform. A newly discovered device with no RMM agent stands out instantly. Unknown device alerts can open a helpdesk ticket automatically with all the context attached, so "there's something new on VLAN 20" becomes a tracked, assigned, resolved item instead of a Slack message everyone forgets by Friday.

Patching and software state live next to the device. When a supply-chain story breaks, you don't reconcile spreadsheets. You open the map, filter to your build and dev segments, see exactly which machines exist there, which are managed, and what's installed — then act from the same console.

Before and after an incident like this GitHub worm:

• Old way: Half a day of manual correlation across four consoles, an answer that's already incomplete, and a note to "do a proper audit someday."
• AlertMonitor way: Open the live topology map, filter to the subnets where build and dev machines live, see every connected device — managed or not — verify which lack agents, check installed software and patch state, and open tracked tickets for the gaps. Minutes, not hours. And next quarter, when it happens again, the map is already accurate.

Practical Steps: Tighten Your Visibility This Week

You don't need to wait for a platform rollout to start closing this gap. Here's what you can do today — starting with the same discovery logic AlertMonitor automates.

1. Sweep your critical subnets and export what's actually live.

From a Windows machine on the segment:

$subnet = "192.168.10"

# Ping sweep to populate the ARP cache
1..254 | ForEach-Object {
    $ip = "$subnet.$_"
    if (Test-Connection -ComputerName $ip -Count 1 -Quiet) { Write-Output $ip }
}

# Export everything the ARP cache learned, with MAC addresses
Get-NetNeighbor -AddressFamily IPv4 |
    Where-Object { $_.IPAddress -like "$subnet.*" -and $_.State -in 'Reachable','Stale' } |
    Select-Object IPAddress, LinkLayerAddress, State |
    Sort-Object IPAddress |
    Export-Csv -Path "C:\Reports\discovered-devices.csv" -NoTypeInformation

From a Linux box, arp-scan gets you IP, MAC, and vendor in one pass:

sudo apt install -y arp-scan
sudo arp-scan --interface=eth0 192.168.10.0/24 | tee discovered-devices.txt

2. Diff discovered devices against your RMM agent inventory to surface unmanaged endpoints.

$discovered = Import-Csv "C:\Reports\discovered-devices.csv"
$agents     = Import-Csv "C:\Reports\rmm-agent-inventory.csv"   # MAC address export from your RMM

$discovered | Where-Object {
    $mac = $_.LinkLayerAddress
    -not ($agents | Where-Object { $_.MACAddress -eq $mac })
} | Select-Object IPAddress, LinkLayerAddress |
  Export-Csv "C:\Reports\unmanaged-devices.csv" -NoTypeInformation

Every row in that output is a device your RMM would miss during an incident. That list is your real blind spot.

3. Inventory the software on your build and dev servers so you can answer "are we exposed?" in minutes, not days.

$servers = Get-Content "C:\Reports\build-servers.txt"

Invoke-Command -ComputerName $servers -ScriptBlock {
    Get-Package -ErrorAction SilentlyContinue |
        Where-Object { $_.Name -match 'node|npm|python|pip|git' } |
        Select-Object PSComputerName, Name, Version
} -ErrorAction SilentlyContinue |
    Sort-Object PSComputerName, Name |
    Export-Csv "C:\Reports\build-server-packages.csv" -NoTypeInformation

On Linux build boxes:

while read -r host; do
  echo "=== $host ==="
  ssh -o ConnectTimeout=5 "$host" 'npm ls -g --depth=0 2>/dev/null || pip list 2>/dev/null | head -25'
done < build-servers.txt

4. Then make it continuous. These scripts give you a snapshot — which is already more than most teams have. But a snapshot taken Monday is wrong by Wednesday. This is the exact workflow AlertMonitor runs for you permanently: continuous SNMP, ARP, and active discovery feeding a live topology map; instant alerts on any new device or dropped link; automatic correlation against your managed endpoint list; and one-click escalation into the helpdesk when something shows up that nobody can account for.

The worm in this story worked because it hid where nobody looks. Most networks are full of devices hiding the same way — not maliciously, just invisibly. Turn the lights on.

Related Resources

AlertMonitor Network Monitoring & Visibility AlertMonitor Platform Overview Book a Demo Network Monitoring & Visibility Resources