Is CVE-2023-36847 (Juniper Junos OS EX Series Missing Authentication for Critical Function) being exploited in the wild?

How to read this CVE in practical terms

For this question, the key issue is not the product name alone, but whether the flaw is being used as a real attack path. CISA’s KEV listing is the strongest public signal for that, and the right operational response is to treat the device as exposed until you have confirmed version, exposure, and possible compromise. For broader triage, the CISA Known Exploited Vulnerabilities Catalog and the CVE Program are the authoritative reference points.

If you are responsible for edge or internet-facing appliances, Juniper Junos OS EX Series should be treated like any other remotely reachable device with an authentication weakness: confirm whether the affected asset is present, whether management interfaces are reachable from untrusted networks, and whether compensating controls actually reduce the attack surface. NHIMG’s Edge Device Security Guide is useful here because it focuses on the operational realities of exposed network devices, including management access and device hardening.

The phrase “missing authentication for critical function” matters because it usually means an attacker does not need prior credentials to reach functionality that should have been protected. In practice, that changes the priority order: exposure assessment comes first, then remediation, then compromise checking. For vulnerability prioritisation, the Zero-Day and Exploited Vulnerabilities Guide and the Vulnerability Management Guide both support that workflow.

Why “being exploited in the wild” changes the response

Once a CVE is in KEV, the question shifts from “Is this theoretically dangerous?” to “How quickly can this be removed from an attacker’s usable path?” Active exploitation means the exploitation window is already open, so standard patch queues and normal maintenance windows may be too slow if the device is internet-facing or critical to operations. Use the KEV listing to justify accelerated remediation and tighter exception handling, especially where the asset is externally reachable.

Failure mechanism: a network-based attacker can reach the vulnerable function without authenticating, then use that access to manipulate file system integrity or other device state in a way the system should have prevented. That kind of flaw is especially important on infrastructure devices because even “limited impact” can still be operationally meaningful when the target is an edge node, a management plane, or a device that sits on a trust boundary.

Impact: the practical risk is unauthorized device manipulation, configuration or filesystem tampering, and the possibility that the appliance becomes a foothold for further interference. Even when the direct effect is bounded, exploitation of perimeter or routing infrastructure can undermine integrity, availability, and trust in adjacent systems.

What practitioners should do while patching or mitigation is pending

First, confirm whether the device is actually in scope and whether it is exposed to untrusted networks. If you cannot patch immediately, reduce exposure rather than waiting for the next maintenance window: restrict management reachability, limit source networks, monitor for suspicious requests, and preserve logs and device state for later review. On edge platforms, reducing reachable surfaces is often the only meaningful interim control.

Second, check for signs that the device was touched before the advisory reached you. That means looking for unusual management actions, unexpected file-system changes, altered configuration, new accounts or admin-like access paths, and any behaviour that does not fit your normal change pattern. If you have reason to believe the device was exposed for a meaningful period, treat post-exploitation review as part of remediation, not as an optional extra.

Third, if the appliance participates in authentication, routing, logging, or configuration distribution, validate downstream dependencies after remediation. A compromised or tampered edge device can create second-order issues even when the original exploit only produced limited direct impact.

Practitioner Guidance

What to prioritise: Treat KEV-listed exploitation as the trigger for emergency triage, not a routine patch ticket. The first decision is whether the device is reachable from untrusted networks or has a management plane that can be abused from outside its intended trust zone.

What to verify: Confirm version scope against the vendor advisory, verify whether the device was exposed during the known exploitation window, and retain logs or config snapshots before making changes. If remediation is delayed, document the compensating control that actually narrows attacker reach, not just the intended one.

Practitioner takeaway: For KEV-listed edge-device flaws, the right mental model is exposure plus trust-boundary risk, not just patch availability, because even a bounded flaw can still be operationally serious when it sits at the perimeter.

Related resources from NHI Mgmt Group

• CVE-2023-36847 (Juniper Junos OS EX Series Missing Authentication for Critical Function)
• CVE-2023-36846 (Juniper Junos OS SRX Series Missing Authentication for Critical Function)
• CVE-2023-36851 (Juniper Junos OS SRX Series Missing Authentication for Critical Function)
• Is CVE-2023-28461 (Array Networks AG and vxAG ArrayOS Missing Authentication for Critical Function) being exploited in the wild?