Is CVE-2024-4358 (Progress Telerik Report Server Authentication Bypass by Spoofing) being exploited in the wild?

Yes. CISA added CVE-2024-4358 to its Known Exploited Vulnerabilities catalogue on 13 June 2024, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Progress Telerik Report Server contains an authorization bypass by spoofing vulnerability that allows an attacker to obtain unauthorized access. Any organisation running the affected product should treat remediation as urgent.

What this means operationally for a KEV-listed authentication bypass

A CISA KEV listing is the practical signal that this is no longer a “watch it” issue, it is a live exploitation problem. For a report server authentication bypass, the first question is whether the product is exposed anywhere, including internet-facing test, staging, or forgotten instances. If it is, treat the issue as an active access-control failure, not just a software defect.

Prioritisation should follow the exploitability signal, not the asset owner’s change window. The right response is to confirm exposure, move the affected system out of reach if you cannot patch immediately, and assume unauthorised access may already have occurred if the service was reachable during the exploitation window. The KEV entry and vendor guidance should drive exact remediation timing and scope.

For readers building a broader response playbook, the same triage pattern used for Zero-Day and Exploited Vulnerabilities Guide applies here: confirm exposure first, then sort out urgency, workaround, and evidence preservation before you normalise the asset back into service.

How to verify exposure and limit the blast radius

Start with asset inventory and service discovery. You want to know where Progress Telerik Report Server is deployed, which environments are reachable externally, and whether any instance is still on a path that an unauthenticated requester can touch. If multiple teams manage the platform, do not rely on application ownership alone because exposed administrative consoles and forgotten replicas are common failure points.

If patching or full shutdown must wait, reduce exposure at the perimeter and at the application edge. Restrict network access to trusted administration paths, remove unnecessary public reachability, and review any reverse proxy, WAF, or access gateway rules that may still permit unauthenticated requests to the vulnerable endpoint. This is containment, not remediation, but it can materially narrow the attack window while fix work proceeds.

Because the direct answer identifies unauthorized access as the consequence, focus verification on whether the server was reachable during the period of known exploitation. That means checking logs for requests to login, admin, or report-generation functions, and looking for newly created accounts, altered configuration, or unusual report exports that could indicate post-bypass activity.

If your environment also depends on the vulnerable service for credentials or integration tokens, the same logic that matters in Dropbox Sign breach 2024 applies: a back-end trust break can expose much more than the application itself, so rotation and access review may be needed after containment.

What to do after remediation if the service was reachable

After you apply the vendor fix or other approved mitigation, do not stop at “patched.” Validate whether the system was exposed long enough for an attacker to enumerate reports, extract data, or establish persistence through application settings. If the instance was externally reachable, treat credential and session review as part of the recovery work, especially where the report server integrates with other internal services or stores reusable secrets.

Post-remediation checks should include account review, administrative action review, and any data-access audit the product can provide. If the server sat behind a shared identity boundary or had privileged service connections, assess whether those adjacent trust paths also need rotation or reissuance. The decision point is simple: if compromise would have granted access to data or linked systems, assume the blast radius extends beyond the report server itself until proven otherwise.

For a similar operational mindset in identity compromise cases, Microsoft Midnight Blizzard breach is a useful reminder that a single bypass or weak access path can become a much broader intrusion if adjacent credentials and recovery paths are not reviewed.

Risk and Threat Considerations

A live exploitation signal changes the risk profile from theoretical exposure to likely abuse. For a report server, the main danger is that an unauthenticated bypass can become an initial foothold for data theft, report tampering, credential discovery, or pivoting into adjacent systems that trust the server.

Failure mechanism: The attacker exploits the authentication or authorization flaw to obtain unauthorized access, then uses the newly gained access to enumerate sensitive content, abuse administrative functions, or harvest downstream secrets and trust relationships.

Impact: The organisation can suffer exposure of business data, integrity loss in published reporting, and follow-on compromise if the report server was connected to privileged internal resources or shared credentials.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation requires fast exposure triage and remediation prioritisation.
Recommendation — Prioritise and remediate the KEV-listed service before lower-risk backlog items.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	KEV exploitation demands finding exposed instances and tracking remediation status.
	SI-2 — Flaw Remediation	The issue is an exploited software flaw that needs urgent remediation or mitigation.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-bypass investigation depends on reviewing logs for unauthorized access.
Recommendation — Scan for exposed installations and verify remediation completion. Apply vendor remediation or approved mitigation as soon as possible. Review audit records for signs of bypass use and post-compromise activity.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	Exploited vulnerabilities require managed triage, remediation and verification.
Recommendation — Track the flaw through remediation, verification, and exception handling.

Practitioner Guidance

What to verify: Confirm whether the affected product is deployed anywhere reachable, whether the vulnerable endpoint was exposed during the KEV window, and whether logs show unauthorised access patterns or unexpected administrative actions.

Decision rule: If the system was internet-facing or otherwise reachable before remediation, treat the issue as potential compromise until your log review and account review prove otherwise. If it was isolated and never exposed, the priority shifts to fix validation and broader inventory hygiene.

Practitioner takeaway: For KEV-listed authentication bypasses, the real question is not whether exploitation is possible, but whether you can still prove the service was not already used as an unauthorised entry point.