This is a booby-trapped brochure, not an unlocked front door
RHSA-2008:1036 is a Firefox client-side rollup for RHEL 4 and 5, not a remotely reachable daemon flaw. The advisory bundles multiple issues fixed in Firefox 3.0.5, including memory-corruption bugs that *could* lead to code execution, same-origin bypasses, XSS/session-restore issues, URL parsing quirks, and CSS parser weirdness. For Red Hat packaging, the relevant fixed builds are RHEL 4: firefox-3.0.5-1.el4, nspr-4.7.3-1.el4, nss-3.12.2.0-1.el4 and RHEL 5: firefox-3.0.5-1.el5_2, nspr-4.7.3-2.el5, nss-3.12.2.0-2.el5, xulrunner-1.9.0.5-1.el5_2.
Vendor CRITICAL is technically understandable because some bundled Mozilla advisories were rated critical and included potential arbitrary code execution during normal browsing. But in a 10,000-host enterprise patch queue, that score overstates today's operational risk: exploitation requires user interaction, an actually installed and used desktop browser on RHEL 4/5, and there is no KEV listing or current exploitation signal. This is real risk on the small number of legacy endpoints that still browse the web, but it is not the same class as an unauthenticated internet-facing RCE.
4 steps from start to impact.
Land the user on hostile content
- A human user must browse to attacker-controlled content
- The target host must have Firefox installed and used interactively
- Outbound web access must be available
- No user, no exploit
- Server-class RHEL deployments often have Firefox installed but never launched
- Email security, web filtering, and browser isolation can kill the lure before execution
Trigger a browser-engine flaw
- Firefox version must be older than the RHSA fixed build
- Exploit content must match the vulnerable engine path
- The user must render the content without the browser crashing before useful impact
- Old browser exploitation is brittle and version-specific
- Mozilla described some RCE paths as presumed-exploitable memory corruption, not turnkey one-click public weaponization
- Tenable still records 'No known exploits are available' for the advisory
Gain same-origin bypass or user-context code execution
- The target user must have valuable session data or enough local privilege to matter
- The attack must escape from mere crash/DoS into reliable control or theft
- Blast radius is usually one user session
- No direct privilege escalation to root is described in the RHSA
- Legacy desktops that still exist are often segmented, kiosked, or low-trust by design
firefox, outbound beacons, dropped files in the user's home, and anomalous proxy activity tied to the interactive account.Operationalize the foothold
- A payload must execute or stolen browser data must be monetizable
- The compromised host must reach further internal assets
- EDR and egress controls commonly catch the post-exploitation phase
- Legacy RHEL endpoints are usually a small, exceptional population rather than broad enterprise standard
- Internal movement still requires separate credentials and reachability
The supporting signals.
| In-the-wild status | No current public evidence of active exploitation found. Tenable's plugin still says 'No known exploits are available'. |
|---|---|
| KEV status | Not KEV-listed based on review against CISA's Known Exploited Vulnerabilities Catalog. |
| Proof-of-concept availability | I did not find a widely used current public exploit repo for this RHSA rollup. Mozilla and Red Hat primarily reference advisories and bug trackers, not a weaponized PoC ecosystem. |
| EPSS | Representative included issue CVE-2008-5507 shows EPSS 0.53% / 64.9th percentile in Feedly's CVE view, sourced from FIRST EPSS. That's not zero, but it is far from 'drop everything'. |
| Vendor baseline | Red Hat marked the advisory Critical and Tenable maps the rollup to CVSS v2 10.0 via AV:N/AC:L/Au:N/C:C/I:C/A:C. |
| CVSS reality check | That vector models the worst RCE path in a vacuum. It misses the practical prerequisites: user interaction, client-side exposure only, and narrow legacy endpoint population. |
| Affected versions | RHEL 4 and 5 systems with Firefox older than the RHSA builds are affected. Upstream Mozilla fixed these issues in Firefox 3.0.5 on 2008-12-16. |
| Fixed versions | RHEL 4: firefox-3.0.5-1.el4, nspr-4.7.3-1.el4, nss-3.12.2.0-1.el4. RHEL 5: firefox-3.0.5-1.el5_2, nspr-4.7.3-2.el5, nss-3.12.2.0-2.el5, xulrunner-1.9.0.5-1.el5_2. |
| Exposure/scanning reality | Internet-exposure engines like Shodan/Censys are the wrong lens here because Firefox is not a listening service. This is a local package inventory problem on interactive Linux endpoints. |
| Disclosure and researchers | Red Hat issued RHSA-2008:1036 on 2008-12-16. Mozilla credits Mozilla developers, moz_bug_r_a4, Chip Salzenberg, and IBM researchers Justin Schuh, Tom Cross, and Peter William across the bundled advisories. |
noisgate verdict.
The decisive downgrading factor is attacker position: this is a client-side browser issue that requires a user to load hostile content, not an unauthenticated service reachable across your estate. The second big dampener is exposure population: the number of enterprises that still have actively browsed Firefox on RHEL 4/5 should be tiny, even if the installed package still shows up in scans.
Why this verdict
- Start from vendor 10.0, then cut hard for client-side reachability: the attacker does not hit a remotely exposed daemon; they need a person to browse to hostile content.
- Cut again for implied prior stage: phishing, malvertising, or web-lure delivery is a separate initial-access step, which means this is downstream of controls like email security, proxy filtering, and browser isolation.
- Cut again for reachable population: only legacy RHEL 4/5 systems with Firefox actually installed and used interactively matter; that is a much smaller slice than the advisory product matrix suggests.
- Cut again for blast radius: successful exploitation lands in the logged-in user's context, not automatic root on a server fleet.
- Keep it at MEDIUM, not LOW: the advisory does include plausible RCE/chrome-privilege paths during normal browsing, so any legacy kiosk, admin workstation, or jump-host with active browser use is still bad debt.
Why not higher?
I am not scoring this HIGH or CRITICAL because the attack chain is stacked with real-world friction: user interaction, client-side execution, legacy platform dependency, and a likely tiny exposed population. There is also no KEV entry or modern exploitation drumbeat to justify emergency treatment across an enterprise fleet.
Why not lower?
I am not dropping this to LOW because some of the included Mozilla issues were explicitly treated as critical by Mozilla and Red Hat due to potential arbitrary code execution or privileged JavaScript during normal browsing. On any still-used legacy endpoint, compromise can still hand an attacker a real foothold.
What to do — in priority order.
- Block legacy browsing paths — If these RHEL 4/5 hosts still exist, stop them from browsing arbitrary internet content by proxy policy, outbound ACLs, or browser isolation. For a MEDIUM verdict there is no mitigation SLA; use this control where patching or retirement cannot happen immediately, then complete remediation within 365 days.
- Inventory actual browser use — Separate 'package installed' from 'browser actually used' by pulling process execution, proxy, and login telemetry. There is no mitigation SLA — go straight to the 365-day remediation window, but do the inventory now so you do not spend cycles patching dead packages on non-interactive servers.
- Retire or isolate legacy endpoints — A host still vulnerable to a 2008 Firefox rollup is almost certainly carrying broader unsupported-software risk. Put those systems into a legacy enclave, strip outbound web access where feasible, and finish remediation or decommissioning within 365 days.
- Hunt for browser-spawned payloads — Use EDR or shell history review to look for unusual child processes from
firefox, suspicious downloads under user homes, or strange outbound sessions. There is no mitigation SLA for MEDIUM, but this is the fastest way to tell whether the residual risk is theoretical or operational.
- A WAF does not help; the vulnerable component is the user's browser, not your web app edge.
- Internet exposure scanning via Shodan/Censys does not help; Firefox is not a listening service and this advisory is a local-package check.
- Treating this like a server RCE and mass-patching every RHEL node with the package present wastes time; the real question is which hosts still browse.
Crowdsourced verification payload.
Run this on the target RHEL host itself as root or with an account that can query the local RPM database. Save it as check_rhsa_2008_1036.sh, then run bash check_rhsa_2008_1036.sh; it checks installed RPM capabilities against the RHSA fixed versions and prints VULNERABLE, PATCHED, or UNKNOWN.
#!/bin/bash
# check_rhsa_2008_1036.sh
# Determine exposure to RHSA-2008:1036 on RHEL 4/5 using RPM package capability/version checks.
# Exit codes: 0=PATCHED/not-applicable, 1=VULNERABLE, 2=UNKNOWN
set -u
have_cmd() {
command -v "$1" >/dev/null 2>&1
}
if ! have_cmd rpm; then
echo "UNKNOWN rpm-not-found"
exit 2
fi
if ! rpm -q firefox >/dev/null 2>&1; then
echo "PATCHED firefox-not-installed"
exit 0
fi
RHEL_MAJOR="$(rpm --eval '%{?rhel}' 2>/dev/null)"
if [[ -z "$RHEL_MAJOR" || "$RHEL_MAJOR" == "%{?rhel}" ]]; then
if [[ -r /etc/redhat-release ]]; then
if grep -q 'release 4' /etc/redhat-release; then
RHEL_MAJOR=4
elif grep -q 'release 5' /etc/redhat-release; then
RHEL_MAJOR=5
else
echo "UNKNOWN unable-to-determine-rhel-major"
exit 2
fi
else
echo "UNKNOWN unable-to-determine-rhel-major"
exit 2
fi
fi
check_req() {
local req="$1"
rpm -q --whatprovides "$req" >/dev/null 2>&1
}
missing=()
case "$RHEL_MAJOR" in
4)
check_req 'firefox >= 3.0.5-1.el4' || missing+=("firefox>=3.0.5-1.el4")
check_req 'nspr >= 4.7.3-1.el4' || missing+=("nspr>=4.7.3-1.el4")
check_req 'nss >= 3.12.2.0-1.el4' || missing+=("nss>=3.12.2.0-1.el4")
;;
5)
check_req 'firefox >= 3.0.5-1.el5_2' || missing+=("firefox>=3.0.5-1.el5_2")
check_req 'nspr >= 4.7.3-2.el5' || missing+=("nspr>=4.7.3-2.el5")
check_req 'nss >= 3.12.2.0-2.el5' || missing+=("nss>=3.12.2.0-2.el5")
if rpm -q xulrunner >/dev/null 2>&1; then
check_req 'xulrunner >= 1.9.0.5-1.el5_2' || missing+=("xulrunner>=1.9.0.5-1.el5_2")
fi
;;
*)
echo "UNKNOWN unsupported-rhel-major-$RHEL_MAJOR"
exit 2
;;
esac
if [[ ${#missing[@]} -eq 0 ]]; then
echo "PATCHED all-required-rpms-meet-rhsa-2008-1036-level"
exit 0
fi
echo "VULNERABLE missing:${missing[*]}"
exit 1
If you remember one thing.
tenable:35191 like an internet-facing emergency across 10,000 hosts. First, identify the small subset of RHEL 4/5 systems where Firefox is actually launched by humans; for those, restrict browsing or isolate the host if it cannot be retired. For this MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window; the noisgate remediation SLA is ≤ 365 days to get the RHSA-fixed packages on any still-legitimate legacy endpoint or, better, remove the browser / decommission the host entirely.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.