How to Fix CVE-2015-7755: Juniper ScreenOS Authentication Backdoor

Patch immediately. This is not a subtle memory-corruption bug that needs a chained exploit. It is a hardcoded administrative password baked into the ScreenOS firmware. Anyone who can reach the SSH or TELNET admin port and knows that password owns the firewall. CISA added CVE-2015-7755 to the Known Exploited Vulnerabilities catalog on 2025-10-02 and tags it as actively exploited and automatable. Treat every internet-reachable ScreenOS device as a priority upgrade, and assume any device that sat exposed has already been touched.

What is CVE-2015-7755?

CVE-2015-7755 is an authentication backdoor in Juniper ScreenOS, the operating system that runs on Juniper NetScreen, SSG, and ISG firewall and VPN appliances. The flaw was unauthorized code that shipped inside several ScreenOS builds. It carries a CVSS 3.1 base score of 9.8 (critical) with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, and CISA classifies it as CWE-287, improper authentication.

The mechanic is blunt. The source record states that affected ScreenOS releases “allow remote attackers to obtain administrative access by entering an unspecified password during a (1) SSH or (2) TELNET session.” In plain terms, there is a magic password. Type it at the login prompt for any administrative username and the device hands you a full system-administrator session. Your real admin credentials, your RADIUS or TACACS+ backend, your local password policy: none of it matters, because the backdoor sits in front of the normal authentication path.

Juniper found this during an internal code review and disclosed it on 17 December 2015 alongside a second issue, CVE-2015-7756, which weakened VPN traffic decryption. The story drew unusual press attention because the code was described as having been inserted without authorization. For an administrator the takeaway is simpler than the headlines: if you run an affected build, the device has a known login bypass and you need to upgrade the firmware.

Here is the exact affected and fixed mapping straight from the record. Affected trains are ScreenOS 6.2.0r15 through 6.2.0r18, and the 6.3.0r12 through 6.3.0r20 trains in their original sub-builds. The fixed sub-builds are 6.2.0r19, then 6.3.0r12b, r13b, r14b, r15b, r16b, r17b, r18b, r19b, and 6.3.0r21. The lettered “b” releases and r21 contain the patch. Juniper bulletin JSA10713 is the canonical source for the download images.

Why it matters in practice: a public proof-of-concept exists, the password is published, and KEV-listed flaws draw continuous internet-wide scanning. There is no skill barrier here. A scanner that finds an open SSH or TELNET port on an unpatched ScreenOS box can authenticate on the first try. An internet-facing management interface with no source-IP restriction is the worst-case configuration and should be treated as already breached.

Am I affected?

You are affected if the device runs ScreenOS and the firmware version falls in the affected set listed in the Affected row above and has not been moved to one of the fixed sub-builds. Junos OS, SRX-series boxes running Junos, and EX/MX gear are not in scope. This is a ScreenOS-only flaw on the NetScreen, SSG, and ISG families.

Log in at the console or over a trusted-network SSH session and check the running firmware:

get system

The header of that output prints the software version, for example Software Version: 6.3.0r17.0. Compare it against the fixed list. If you are on 6.2.0r15 through r18, or on any 6.3.0r12 through r20 build that does not end in the fixed “b” suffix (or is below r21), the backdoor is present. When in doubt, treat the device as affected and upgrade.

How to fix CVE-2015-7755

The fix is a ScreenOS firmware upgrade to a fixed build. There is no operating-system package manager involved. These are network appliances, not Linux or Windows servers, so apt, dnf, yum, winget, and softwareupdate have nothing to do with this device. You download a signed ScreenOS image from Juniper and load it onto the firewall.

Upgrade the ScreenOS firmware

1. Sign in to the Juniper support portal and open bulletin JSA10713. Download the fixed ScreenOS image for your exact train. For a 6.3.0r17 device that means 6.3.0r17b or later; for 6.2.0 devices that means 6.2.0r19. Match the image to your hardware platform.
2. Back up the current configuration before touching firmware:

save config to tftp 10.10.10.5 ns-config-backup.cfg

3. Stage the new image. From a TFTP server on the management network:

save software from tftp 10.10.10.5 ssg5ssg20.6.3.0r19b.0 to flash

Or, if you are working at the console with a USB stick:

save software from usb ssg5ssg20.6.3.0r19b.0 to flash

4. Reboot to load the patched firmware:

reset

The device prompts to save any unsaved changes and then reboots into the new image. On a high-availability NSRP cluster, upgrade the backup node first, fail over to it, then upgrade the former primary so you keep the firewall path up through the change.

After the upgrade

1. Because the bypass let anyone in as admin, assume the credentials and config could have been read. Rotate all local admin passwords, the RADIUS/TACACS+ shared secrets, any IKE pre-shared keys, and SNMP community strings.
2. Review the config for unexpected admin accounts, changed management-access settings, or new policies that an intruder could have added.
3. Confirm the running version with get system and verify it matches a fixed build.

If you can't patch immediately

You cannot disable this backdoor with a config knob — the only real fix is the firmware upgrade. What you can do is shrink the set of hosts that can ever reach the admin interface, which removes the attacker's path to the magic password.

Lock down management access

First, turn off TELNET management entirely. Cleartext TELNET admin has no place on an internet-facing firewall, and it is one of the two vectors named in the advisory:

unset interface ethernet0/0 manage telnet

Then restrict who may reach the management plane at all. ScreenOS lets you pin administrative access to a specific source subnet:

set admin manager-ip 10.10.10.0 255.255.255.0
save

With a manager-ip set, only hosts inside that range can open an admin session to the device, so a host on the public internet never gets to the login prompt where the backdoor lives. Pair this with an upstream firewall or ACL that drops inbound TCP/22 and TCP/23 to the firewall's management addresses from anything outside your bastion range. These steps are a stopgap. Schedule the firmware upgrade and treat it as the actual remediation.

How to verify the fix worked

Confirm the patched build is the one actually running, then confirm the exposure is closed.

Run get system and read the Software Version line. It must show a fixed build — 6.2.0r19, a 6.3.0r12b through r19b release, or 6.3.0r21. If it still shows an affected build, the image did not load and the backdoor is still live.

Next, prove the management plane is no longer reachable from untrusted networks. From a host outside your admin range, confirm the SSH and TELNET ports do not answer:

nmap -Pn -p 22,23 firewall.example.net

Both ports should read filtered or closed from the outside. Finally, re-run an authenticated vulnerability scan with current signatures and confirm the scanner no longer flags CVE-2015-7755 against the device.

References

• Official vendor advisory: https://supportportal.juniper.net/s/article/2015-12-Out-of-Cycle-Security-Bulletin-ScreenOS-Multiple-Security-issues-with-ScreenOS-CVE-2015-7755-CVE-2015-7756
• NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2015-7755
• CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• CISA KEV entry: "Juniper ScreenOS Improper Authentication Vulnerability" - added 2025-10-02
• Additional reference: http://arstechnica.com/security/2015/12/unauthorized-code-in-juniper-firewalls-decrypts-encrypted-vpn-traffic/
• Additional reference: http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10713
• Additional reference: http://twitter.com/cryptoron/statuses/677900647560253442
• Additional reference: http://www.forbes.com/sites/thomasbrewster/2015/12/18/juniper-says-it-didnt-work-with-government-to-add-unauthorized-code-to-network-gear/

Assembled from the official vendor advisory, the NVD record, and the CISA KEV listing on 2026-05-25. Always confirm against the vendor advisory before applying changes in production.

Why this backdoor is different from a normal CVE

Most critical CVEs are exploitation puzzles. An attacker has to line up a memory layout, defeat ASLR, or chain two bugs to land code. CVE-2015-7755 has none of that friction. The unauthorized code added a second, hidden credential check that runs before ScreenOS evaluates your real authentication. When the supplied password matches the embedded string, the device skips every other check and grants a system-level admin session. There is no payload to craft and no timing window to hit. The attacker types a known string and is in.

That changes how you should prioritise. A normal critical bug on an internal-only firewall can sometimes wait for a maintenance window. This one cannot, because the value of the attack to an adversary is enormous and the effort is near zero. The device is a security boundary. Whoever holds admin on a ScreenOS firewall can read and rewrite the security policy, export configuration, stand up a tunnel into the protected network, or quietly disable logging. A firewall compromise is rarely the end of an intrusion; it is the pivot point for everything that follows.

It is worth separating the two issues Juniper disclosed together. CVE-2015-7755 is the administrative login bypass over SSH and TELNET that this page covers. The sibling, CVE-2015-7756, weakened the VPN so that captured IPsec traffic could be decrypted. They were found in the same code review and fixed in the same set of ScreenOS images, which is why the JSA10713 bulletin and the fixed-build list cover both. If you are patching for one, you are patching for both at the same time, so verify your target image addresses the authentication backdoor specifically.

Building the affected inventory

The hardest part of remediating an old appliance CVE is usually not the upgrade itself. It is finding every box that runs the vulnerable code. ScreenOS hardware tends to outlive the team that deployed it, so the NetScreen, SSG, and ISG units in scope are often at branch sites, in colo racks, or behind an acquisition that nobody fully inventoried. Start from whatever source of truth you trust least and verify it against the devices directly.

For each candidate device, the authoritative check is the firmware string itself. Console in or connect over a trusted-network session and read the version:

get system

Read the Software Version line and the platform name in the same output. You need both: the version to judge whether the backdoor is present, and the platform to pick the correct image file when you download the fix. A 6.3.0r17.0 string on an SSG-5 needs a different image than the same version on an ISG-1000, even though the fixed sub-build letter is the same. Record the pair for every device before you start downloading anything, so the upgrade phase is just matching files to a list you already trust.

If you cannot reach a device interactively, do not guess from a spreadsheet. An incorrect version assumption is exactly how a patched fleet ends up with one forgotten box still carrying the backdoor, and a single exposed unit is enough. When you genuinely cannot confirm a version, treat the device as affected and schedule the upgrade.

Containment while you wait for the upgrade window

The firmware upgrade is the only true fix, but you may have devices you cannot reboot for hours. In that gap, your job is to make the login prompt unreachable from anywhere an attacker lives. The backdoor cannot be triggered by a host that never reaches the management plane, so source restriction buys you real protection while images stage.

Disable cleartext TELNET management first. It is one of the two named vectors and has no business answering on a firewall:

unset interface ethernet0/0 manage telnet

Then pin administrative access to a known-good management range so the public internet never reaches the prompt:

set admin manager-ip 10.10.10.0 255.255.255.0
save

Back that up at the perimeter. An upstream ACL or screening device that drops inbound TCP/22 and TCP/23 to the firewall's management addresses gives you a second independent layer, so a mistake in one place does not reopen the path. None of this removes the embedded password. It only narrows who can present it, which is why every one of these steps is a stopgap that ends when the patched image boots.

What to assume if the device was internet-facing

Because the bypass grants full admin with no trace of a failed login, you cannot prove a quiet abuse did not happen by reading the logs. For any device that sat reachable from an untrusted network on an affected build, plan the recovery as if an intruder held admin at some point. That posture is cheaper than a breach you missed.

Rotate everything the admin session could read or change: local admin passwords, the RADIUS and TACACS+ shared secrets, every IKE pre-shared key terminating on the device, and all SNMP community strings. Then audit the configuration line by line for anything an attacker would add and you would not notice in passing. Look for unfamiliar admin accounts, loosened management-access bindings, new address objects or policies that permit traffic you never intended, and any route or tunnel that does not map to a documented service. If the device anchors site-to-site VPNs, remember the sibling decryption flaw means previously captured tunnel traffic may also be exposed, so treat the keys as burned and re-key rather than reuse.

Sequencing the upgrade on production firewalls

On a standalone device the upgrade is a stage-and-reboot, and the reboot means a brief outage of every flow through that firewall. Schedule it, notify the owners, and have console access ready in case the device does not come back cleanly on the new image. Keep the configuration backup you took before staging within reach so you can roll back if the new build misbehaves on your specific platform.

On a high-availability NSRP cluster you can avoid the full outage. Upgrade the backup node first, confirm it boots a fixed build with get system, then fail over so it carries traffic. Upgrade the former primary, confirm its version, and you have moved the whole pair onto patched firmware while keeping the firewall path up through the change. The order matters because a half-upgraded cluster running mismatched ScreenOS versions can behave unpredictably during failover, so do not leave the pair split longer than the upgrade requires.

Related fixes

Additional nearby issues sensible to fix in the same maintenance window:

• How to Fix CVE-2026-21910: Denial of Service in Junos OS
• How to Fix CVE-2026-21905: Denial of Service in Junos OS
• How to Fix CVE-2023-36845: Arbitrary File Read in Junos OS
• How to Fix CVE-2026-21914: Critical Vulnerability in Junos OS
• How to Fix CVE-2023-36851: Juniper Networks Junos OS (Bundle Sibling)