The Register's reporting this week is blunt: additional JFrog Artifactory vulnerabilities are being actively exploited in the wild, and all three have patches available. Their advice — "if you're waiting for a sign to upgrade to a fixed version: this is it" — is exactly right.
Good advice, but it skips the step that actually decides whether your week gets ruined: finding where Artifactory is running in the first place. Think about the last time a story like this broke. An exploit advisory lands Monday morning. Someone forwards it to the IT distro. Your manager asks the question every sysadmin dreads: "Are we exposed?" If your honest answer is "give me a few hours" — because the asset inventory is a spreadsheet from last year, your RMM only sees machines with agents installed, and nobody is entirely sure what lives on the engineering VLAN — then your real problem isn't patching. It's visibility. That's what this post is about.
The Real Problem Isn't the Patch. It's That You Can't See What Needs Patching.
Your asset inventory is a snapshot pretending to be a system. Most IT teams assemble "what's on the network" from four disconnected sources: the RMM's agent list, a vulnerability scanner that runs monthly, a CMDB last touched during an audit, and a Visio diagram from 2019. Every one of them is a point-in-time snapshot, and every one is stale the moment a new VM boots.
Agent-based RMM is blind by design. Ninja, ConnectWise, Datto — excellent at managing endpoints that have agents. Completely silent about anything that doesn't. An Ubuntu VM a developer built two years ago as a local package cache? No agent, no monitoring, no CMDB entry, and — thanks to a NAT rule someone added for a vendor demo and never removed — reachable from outside. That box is now the most dangerous machine on your network, and it appears in none of your tools. This is exactly the scenario where an actively exploited Artifactory CVE turns into an incident: attackers scan for exposed instances continuously, while your next quarterly scan is 30 days away.
The cost shows up the moment an advisory drops:
- 3–6 hours of hunting per site: grep the RMM, email three people asking "do we use this?", pull firewall logs looking for traffic on 8081/8082, walk the server room checking for blinking lights.
- For an MSP, multiply that by every client. Twelve clients means a full day of "are we exposed?" tickets before the first patch gets pushed.
- Patching completes on the documented instances — and the forgotten one stays vulnerable for weeks. That gap between "patch deployed" and "everything patched" is precisely the window attackers work with.
- Meanwhile ticket volume spikes, SLA reporting falls apart because the helpdesk has no data about what actually happened on the network, and the on-call tech who got paged at 2am for something discovery should have surfaced months ago loses another bit of trust in the tooling.
Why the gaps exist: siloed architecture. The RMM has a database of agents. The network team has their own monitoring. The helpdesk knows about symptoms, not topology. Nothing shares data, so the answer to "what's actually on the network?" gets assembled by hand from five sources, every single time something breaks or a CVE goes public.
How AlertMonitor Closes the Visibility Gap
Continuous discovery, not snapshots. AlertMonitor continuously discovers and maps every device on the network — switches, firewalls, access points, printers, IP cameras, unmanaged endpoints — using SNMP, ARP, and active scanning. If it touches the network, it lands on the map automatically. No agent required.
A live topology map that's always current. When a switch goes offline, a link drops, or a new device appears, an alert fires instantly with full network context: which switch, which port, which VLAN, MAC vendor, first-seen timestamp. You stop grepping firewall logs and start looking at an accurate picture of what's actually there — right now, not as of last quarter.
New-device alerts as an early warning system. A new host appears on a server VLAN at 2pm on a Tuesday; you know about it at 2pm on a Tuesday — with its MAC, switch port, and location. Expected devices (printers, IP cameras) get allowlisted per VLAN; everything else gets flagged. That's the difference between managing assets and hosting liabilities.
The workflow changes shape. Old way: read advisory → grep RMM → email around → pull firewall logs → reconcile a spreadsheet → patch what you found → hope. AlertMonitor way: read advisory → search the live inventory → the map shows every host, managed or not, with location context → tag the instance → create the ticket → push the patch → re-scan verifies the fix. Elapsed time: minutes, not days. And because monitoring, helpdesk, RMM, and patch management live in one product, nothing gets copy-pasted between tools and nothing falls through the cracks between them.
For MSPs: one NOC dashboard across every client site, per-site new-device alerting, and inventory exports that turn "client security posture" from a guess into a report you can hand over during a QBR or an audit.
What to Do Today: A Practical Action Plan
Step 1 — Find every Artifactory instance on your network. Right now.
On Windows servers, check for the Artifactory service across your inventory:
# Check every server in your inventory for an Artifactory service
$servers = Get-Content "C:\inventory\servers.txt"
foreach ($s in $servers) {
$svc = Get-Service -ComputerName $s -Name "ArtifactoryService" -ErrorAction SilentlyContinue
if ($svc) {
Write-Output "$s : Artifactory found - Status: $($svc.Status)"
}
}
Or sweep Active Directory for servers you may have forgotten to inventory:
# Scan all domain-joined Windows Servers for an Artifactory service
Get-ADComputer -Filter {OperatingSystem -like "*Server*"} | ForEach-Object {
if (Get-Service -ComputerName $_.Name -Name "ArtifactoryService" -ErrorAction SilentlyContinue) {
Write-Output "$($_.Name) : ArtifactoryService present"
}
}
Sweep your subnets for Artifactory's default ports (8081/8082) — this is what catches the agentless and undocumented instances:
# Sweep a /24 for hosts listening on Artifactory's default ports (PowerShell 7+)
$subnet = "10.10.5."
1..254 | ForEach-Object -Parallel {
$ip = $using:subnet + $_
foreach ($port in 8081, 8082) {
if (Test-NetConnection -ComputerName $ip -Port $port -InformationLevel Quiet -WarningAction SilentlyContinue) {
Write-Output "$ip : port $port open (possible Artifactory)"
}
}
} -ThrottleLimit 64
On Windows PowerShell 5.1, drop -Parallel and -ThrottleLimit 64 and accept the slower run.
From a Linux jump host, nmap does the same job in seconds:
nmap -p 8081,8082 --open -T4 10.10.5.0/24
On any Linux host the sweep turns up, confirm it's actually Artifactory and capture the exact version:
systemctl status artifactory.service
# Pull the exact version via the REST API (use a read-only service account)
curl -s -u "$ART_USER:$ART_PASS" "http://localhost:8081/artifactory/api/system/version" | jq -r .version
Step 2 — Patch, then verify.
Compare the reported version against JFrog's fixed release, upgrade, then re-run the same API call and confirm the new build number. A patch you haven't verified is a patch you can't report — and "we deployed it" is not an audit answer.
Step 3 — Make discovery continuous instead of an emergency project.
- Enable SNMP on every switch and firewall so AlertMonitor maps links and neighbors, not just IP addresses.
- Turn on new-device alerts and route them to a channel your team actually reads.
- Allowlist expected devices per VLAN (the printers, the IP cameras), and treat everything else — especially anything new appearing on a server VLAN — as a ticket-worthy event.
Step 4 — Close the loop in one tool.
The next "are we exposed?" Monday is coming — there is always a next one. The answer should be a 60-second inventory search, a ticket, a patch push, and a verification scan. Not a fire drill. Discovery that finds the forgotten VM, the live map that shows where it lives, the alert that fired the moment it appeared, and the patch workflow that fixes it — all in one platform, with one source of truth.
The Artifactory bugs under attack right now all have patches. The only question that matters is whether you can see every instance that needs one. If you can't answer that in five minutes, fix the visibility first — everything else gets easier after that.
Related Resources
AlertMonitor Network Monitoring & Visibility AlertMonitor Platform Overview Book a Demo Network Monitoring & Visibility Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.