PatchDay Alert
Analysis · 5 min read · 908 words By analysis-desk

When the catalog says 'authenticated' and the researcher says it isn't

The KEV entry for CVE-2023-40044 calls it an authenticated attack. The researchers who found it demonstrated remote code execution with no login at all. When your authoritative sources disagree about whether a bug needs credentials, plan around the scarier answer.

When the catalog says 'authenticated' and the researcher says it isn't

Read the official descriptions of CVE-2023-40044 and you get a mixed message. The CISA KEV entry describes it as a deserialization flaw that “allows an authenticated attacker to execute remote commands.” NVD scores it 8.8 with privileges-required set to low, which is the score’s way of saying you need some level of access first. But Assetnote, the firm that discovered it, demonstrated remote code execution against WS_FTP’s Ad Hoc Transfer module with no authentication at all, via a single HTTP request. Progress’s own advisory treated it as critical. So which is it: a bug that needs a login, or one that doesn’t?

This isn’t a pedantic scoring quibble. It’s a real and recurring triage problem, and how you resolve it changes how you prioritize the patch.

What the bug is

CVE-2023-40044 is a .NET deserialization vulnerability (CWE-502) in the Ad Hoc Transfer module of Progress WS_FTP Server, reachable through the product’s IIS HTTP modules. Deserialization of attacker-controlled data leads to command execution on the underlying Windows host. It affects WS_FTP Server versions before 8.7.4 and 8.8.0 through 8.8.1; the fixes are 8.7.4 and 8.8.2. Progress shipped the update on September 27, 2023, a public proof-of-concept followed within about two days, and CISA added it to the Known Exploited Vulnerabilities catalog on October 5 with an October 26 deadline and the ransomware flag. Assetnote noted roughly 2,900 internet-exposed WS_FTP instances with the necessary web component, skewing toward large enterprises, governments, and universities.

This was also, notably, Progress’s second perimeter-software crisis of 2023, arriving months after the MOVEit Transfer mass-exploitation campaign. Same vendor, same general product category, same year.

The disagreement that matters

The 8.8-versus-9.8 gap comes down to one CVSS metric: privileges required. NVD rated it “low,” which caps the score at 8.8. The discoverer’s position, backed by a working exploit, is that no privileges are required, which would make it 9.8. The KEV catalog’s prose inherited the “authenticated” framing. So you have authoritative-sounding sources pointing in different directions, and a defender skimming the NVD number could reasonably conclude this bug needs an attacker to already have a foothold, and slot it below the unauthenticated criticals.

That conclusion would be wrong, and the way to avoid it generalizes into a triage rule worth adopting:

  • When sources disagree about whether a bug needs authentication, default to the unauthenticated interpretation until you’ve confirmed otherwise. The cost of treating an authenticated bug as unauthenticated is a slightly-too-fast patch. The cost of treating an unauthenticated bug as authenticated is leaving a pre-auth RCE in your “needs a foothold first, lower priority” bucket while it’s being mass-exploited. Those risks are not symmetric.
  • The CVSS base score is an input, not a verdict. It’s computed from a vector that someone chose, and the choices can be conservative, contested, or simply wrong for your environment. A bug that’s 8.8 on paper because of a debatable PR:L can be a 9.8 in practice.
  • Read the researcher’s writeup, not just the database entry. The people who found the bug usually describe the actual exploitation conditions in detail. For CVE-2023-40044, Assetnote’s analysis made the unauthenticated reality plain, even where the aggregated metadata blurred it.
  • Official descriptions lag and inherit errors. The KEV text and the NVD vector are maintained by people working from limited information under time pressure. They’re valuable and they’re not infallible, especially on the auth/no-auth distinction that matters most for prioritization.

What to do

  • Patch WS_FTP Server to 8.7.4 or 8.8.2 or later. Given it’s a publicly-exploited, ransomware-flagged RCE that is in practice unauthenticated, treat it as critical regardless of the 8.8 label.
  • Get the WS_FTP web interface and Ad Hoc Transfer module off the internet if you don’t need them exposed, and disable the Ad Hoc Transfer module if it’s unused. The exposed web component is what makes the bug reachable.
  • Assume compromise on long-exposed, unpatched instances. With a PoC out since late September 2023, an internet-facing server that lagged on patching should be investigated for web shells, unexpected child processes of the IIS/WS_FTP worker, and outbound connections.
  • Encode the triage rule into your process. When you assess a new CVE, explicitly check whether the authentication requirement is settled. If the database says authenticated but a credible researcher demonstrates otherwise, prioritize as unauthenticated and note the discrepancy.

The reframe is about where authority actually lives in vulnerability data. The KEV catalog and NVD are the right starting points, and you should track both, but they aggregate and simplify, and on the single most important triage question, whether an attacker needs to log in first, they’re sometimes wrong. CVE-2023-40044 is a clean example: scored and described as if it needed authentication, exploited in the wild without any. Plan around the exploit reality, not the metadata, and when the two disagree, give the attacker the benefit of the doubt. We read the researcher writeups behind the catalog entries for exactly these cases, because the difference between “authenticated” and “not” is the difference between a patch that can wait and one that can’t.

Sources

Share

Related field notes

One email, every weekday morning.

You're in. Check your inbox.

Get the digest

Free. Weekday mornings. Plain English CVE triage.

Check your inbox to confirm.