Today’s Topics:

• Squidbleed Shows Why Old Proxy Code Still Belongs in the Threat Model
• FortiBleed Shows Why Firewall Credentials Are Now Perimeter Risk
• How can Netizen help?

---

Squidbleed Shows Why Old Proxy Code Still Belongs in the Threat Model

Squidbleed is the kind of vulnerability that looks small in code and much larger in an environment diagram. Tracked as CVE-2026-47729, the flaw is an out-of-bounds read in Squid’s FTP gateway that can leak fragments of proxy memory back to a client. In the worst case, that memory may contain another user’s cleartext HTTP request, including an Authorization header, bearer token, API key, session cookie, or other credential material that was never meant to leave the proxy process.

The bug is being compared to Heartbleed for a reason. This is not remote code execution. It does not give an attacker shell access, modify traffic, or knock the service offline. It reads memory past the intended boundary and returns data that should have stayed inside the process. That makes the vulnerability easier to underrate if teams focus only on exploit categories, yet memory disclosure against a shared proxy can still be a direct path to account takeover. If a leaked header contains a valid token, the attacker does not need to exploit the victim’s endpoint. They can simply reuse what the proxy exposed.

The threat model is narrow, but realistic. Squid describes the attacker as a trusted client, meaning someone already permitted to send traffic through the proxy. That matters in environments where Squid is used as a shared forward proxy for schools, enterprises, guest networks, public Wi-Fi, managed networks, or filtering gateways. The attacker does not need to be an external internet host hitting Squid from the outside. They need access as a proxy user, a Squid instance with FTP gateway functionality available, and an FTP server they control or can influence.

That limitation is also what makes the bug easy to miss during risk scoring. CVSS places it in the moderate range with network attack vector, low attack complexity, low privileges required, no user interaction, high confidentiality impact, and no integrity or availability impact. On paper, that looks contained. In practice, a shared proxy is a collection point for other people’s requests. A confidentiality-only vulnerability in that position can still expose high-value secrets.

The exposed traffic is also bounded. Standard HTTPS traffic sent through an HTTP CONNECT tunnel remains opaque to Squid, so Squidbleed does not magically decrypt the modern web. The most direct exposure is cleartext HTTP. The risk expands in deployments where Squid is configured to terminate or inspect TLS, such as SSL Bump environments, since the proxy can then see decrypted request contents before forwarding them upstream. Legacy internal applications, captive portals, old appliances, device management pages, and operational tools are the kinds of places where cleartext HTTP still tends to survive longer than security teams expect.

The root cause sits in Squid’s FTP directory-listing parser. FTP directory listings are messy, old, and inconsistent across server implementations, so Squid contains parsing logic meant to turn FTP listings into something usable for clients. The vulnerable behavior traces back to compatibility handling introduced in 1997 for NetWare-style listings, where extra whitespace could appear between a timestamp and a filename.

The parser advances a pointer after a parsed timestamp and then skips whitespace before treating the next bytes as the filename. The edge case appears when a crafted FTP listing line ends right after the timestamp and provides no filename at all. At that point, the pointer lands on the string terminator. The relevant C library behavior is the catch: strchr can match the terminating null byte in a string. If code asks whether that terminator appears inside the whitespace string, it can get a positive result. The parser then advances past the end of the intended buffer and keeps reading until it finds a byte that stops the scan.

That is where an old parser bug turns into a data exposure issue. Squid reuses memory buffers, and reused heap memory may still contain data from prior transactions. If a buffer recently held part of a different user’s HTTP request, a crafted FTP listing can overwrite only a small portion of that buffer and cause Squid to return the remaining stale bytes as if they were part of an FTP filename. The attacker sees the data in the generated FTP directory response.

Calif.io’s demonstration showed an Authorization header leaking from another client using the same proxy. That is the security impact in one line: a user who is allowed to use the proxy may be able to trigger a malformed FTP response and receive secrets from unrelated traffic handled by the same Squid process.

The fix itself is small. Squid patched the FTP gateway parsing logic by checking for the null terminator before using the character membership test that caused the over-read. The official advisory lists Squid versions older than 7.6 as affected, with Squid 4.x, 5.x, 6.x, and 7.x through 7.5 vulnerable. Squid versions older than 3.5.28 were not tested and should be treated as vulnerable. Operators using vendor-packaged builds should rely on distribution advisories and backported package fixes rather than only checking the upstream version string.

That distinction matters. Enterprise Linux distributions often backport security patches into older package versions. An environment may still show a Squid 5.x or 6.x package and be patched, or it may show a seemingly familiar package version that still lacks the fix. Ubuntu, for example, lists fixed Squid packages for supported releases such as 22.04 LTS and 24.04 LTS. Debian’s tracker shows fixed status for some releases and vulnerable status for others. The right validation step is to confirm the vendor package status or inspect whether the FtpGateway.cc guard is present.

The better mitigation, where operations allow it, is to disable FTP through Squid entirely. FTP is a legacy protocol with little place in most modern browser-driven networks. Chrome removed FTP URL support years ago, and many organizations have little legitimate need for proxy-mediated FTP access. Squid’s own advisory provides a workaround that denies FTP traffic through the proxy, with an optional allowlist for trusted FTP destinations. In many networks, the safer answer is no allowlist at all.

Blocking outbound TCP port 21 from the proxy can also reduce practical exploitability, but it should be treated as a compensating control rather than the full fix. A proxy policy change inside squid.conf is more direct, and a patched package removes the parser bug itself. Organizations should also review whether Squid is performing TLS interception, whether cleartext HTTP remains in use internally, and whether proxy users are segmented by trust level. A guest network user and a corporate endpoint should not be sharing sensitive proxy memory in the same risk bucket.

Detection is not straightforward. A successful attempt may look like FTP traffic through Squid to an attacker-controlled server, followed by abnormal directory listing responses. Security teams can review Squid access logs for unexpected ftp:// requests, outbound connections to untrusted FTP servers, and spikes of repeated FTP listing activity from a single proxy client. Network controls can flag outbound FTP from proxy infrastructure, especially in environments that do not use FTP operationally. Still, the absence of obvious logs should not be treated as proof of safety. Memory disclosure vulnerabilities rarely leave clean, high-confidence forensic markers.

The incident response question is less about wiping systems and more about credential exposure. If an organization confirms exploitability or suspicious FTP traffic through a vulnerable Squid instance, it should identify which applications and internal services still sent cleartext HTTP through that proxy. Tokens, API keys, basic authentication headers, session cookies, and service credentials exposed over HTTP should be rotated. Legacy internal applications that still rely on cleartext authentication deserve extra attention, as they are exactly the kind of systems that turn a moderate proxy bug into a real identity problem.

Squidbleed also says something broader about aging internet infrastructure. The vulnerable logic survived for nearly three decades in a mature, widely deployed open-source proxy. It sat in compatibility code for an old FTP listing format tied to platforms most modern defenders will never touch. That is not an indictment of Squid alone. It is a reminder that mature software often carries protocol support, parser logic, and compatibility branches that outlive their original use case by decades.

The AI angle is real, but it should not be exaggerated. Calif.io credited Anthropic’s Claude Mythos Preview with surfacing the strchr behavior quickly during research into Squid’s FTP state machine. That does not mean AI agents are suddenly replacing security engineering. It means they are becoming useful at finding weird interactions between old parser code, language semantics, and forgotten protocol features. For defenders, the lesson is practical: AI-assisted review may be most valuable in the code nobody wants to audit by hand anymore.

---

FortiBleed Shows Why Firewall Credentials Are Now Perimeter Risk

FortiBleed is not being treated as a new Fortinet zero-day, and that may be the most useful detail in the story. The campaign is larger than a single vulnerability bulletin. It is a credential problem at perimeter scale, involving internet-facing FortiGate firewalls and SSL VPN gateways where valid logins, old password hashes, weak account hygiene, and exposed management paths appear to have converged into a large verified access dataset.

CISA issued guidance after reports that malicious actors were using compromised credentials against Fortinet devices across government and private-sector networks. The public numbers vary by source and date. CISA referenced leaked credentials tied to about 74,000 Fortinet devices. SOCRadar later reported 86,644 compromised FortiGate devices, more than 80,000 unique IPs, 22,405 domains, and exposure across 194 countries. Arctic Wolf placed the confirmed range between 30,000 and 75,000 devices in its June analysis, citing differences in dataset validation and source reporting. The exact count matters less than the operating model: the actors were not guessing at a few exposed VPN portals. They were building a verified inventory of working perimeter credentials.

Fortinet has pushed back on the idea that FortiBleed is tied to a new product flaw. In its June 19 PSIRT post, the company said the activity appears to involve reused credentials from prior incidents and brute-force activity against devices with weak password hygiene and no MFA. Fortinet also said it was not related to any current incident or advisory. That distinction is technically meaningful. It also should not make defenders comfortable. A valid firewall login obtained through credential reuse can be just as operationally useful as access gained through an exploit chain.

The risk starts with what FortiGate devices are. These appliances often sit at the boundary between the public internet and internal networks. They terminate VPN access, enforce firewall policy, route traffic, hold certificates, connect to identity providers, and often integrate with Active Directory, LDAP, RADIUS, TACACS+, SAML, or other authentication systems. Administrative access to that control plane gives an attacker far more than a login screen. It can provide network topology, user access paths, VPN visibility, configuration data, and a starting point for lateral movement.

SOCRadar described FortiBleed as an automated operation built in two stages. The first stage tests curated username and password combinations against internet-facing Fortinet endpoints. The second stage reportedly uses successful access to collect more credentials from traffic passing through the device, feeding those credentials back into the same access operation. Dutch NCSC also warned that researchers had seen attackers collect packet captures from Fortinet systems in several cases, creating the possibility that more authentication material was exposed after initial firewall access.

That is what makes this different from a normal credential stuffing story. The firewall is not just the target. Once compromised, it can become a collection point. A compromised SSL VPN or firewall appliance may expose user names, VPN sessions, internal addressing, authentication integrations, service accounts, and administrative behavior. If the appliance is tied into directory services, the downstream risk moves into identity infrastructure. Fortinet’s own guidance says that if AD or LDAP integration is configured, that account should be treated as compromised and monitored for use elsewhere.

The older credential storage behavior adds another layer. Fortinet’s technical guidance says FortiOS 7.2.11, 7.4.8, and 7.6.1 introduced PBKDF2 for administrator password storage, replacing SHA-256-based storage. The migration is conditional. After an upgrade from an older version, administrator passwords can remain stored as SHA-256 hashes until the corresponding administrator logs in after the upgrade. Fortinet also notes that older SHA-256 values may remain in a hidden old-password setting for backward compatibility, visible in configuration backups taken by a super admin account.

That matters for two reasons. First, SHA-256 is fast. Fast hashing is bad for password storage when an attacker can obtain hashes and work offline with GPU cracking rigs. Second, many organizations treat firmware upgrades as complete once the version number changes. In this case, the version number alone may not remove the weaker stored credential material. Admin logins, password resets, and Fortinet’s weaker-encryption lockout setting may still be needed to move accounts away from legacy hash exposure.

This is why “patch and move on” is too narrow here. Updating FortiOS is part of the response, but FortiBleed is about credential state, session state, configuration state, and exposure state. A firewall can be on a newer train and still carry old credential baggage. A password can be complex and still be compromised if it was reused, leaked, harvested from an earlier incident, or cracked from a stored hash. An admin interface can be patched and still risky if it remains reachable from the public internet.

The account patterns reported by SOCRadar point to basic but damaging failures. Generic admin accounts and Fortinet system-style accounts accounted for a large share of the exposed credentials. Organization-specific accounts also made up a significant portion of the dataset, which suggests the campaign reached beyond factory naming conventions and default behavior. This is a familiar perimeter problem: predictable account names reduce attacker cost, password reuse extends breach life, and exposed management interfaces let attackers test access at internet scale.

For attackers, a valid FortiGate credential can be more valuable than a workstation foothold. It may allow rule changes, VPN account creation, configuration export, traffic capture, route manipulation, certificate inspection, logging changes, and stealthy access maintenance. A firewall is also a trust anchor in many environments. Security tools often assume it is enforcing policy correctly. If an attacker controls or modifies that enforcement point, detections inside the network may see only the later stages of an intrusion.

That is the defensive lesson. FortiBleed should be treated as an identity incident and a perimeter device incident at the same time. Ending active SSL VPN and administrative sessions is the containment step that breaks live access. Password resets address known and unknown credential exposure. MFA limits replay. PBKDF2 migration reduces the value of stolen configuration hashes. Management access restrictions reduce the number of systems attackers can test. Log review determines whether the appliance was just exposed or actually used as a pivot.

The log review should be wide. Firewall and VPN logs can show unexpected administrator access, unfamiliar source IPs, strange login times, failed sprays, successful logins after long dormancy, new local users, password resets, policy changes, route changes, certificate changes, and configuration exports. Domain controller and identity logs can show lateral movement after the perimeter event, such as unusual use of LDAP bind accounts, new privileged accounts, VPN users authenticating from rare geographies, or service accounts appearing outside their normal pattern. Configuration comparison against a known-good backup can catch subtle persistence that normal event review may miss.

The response also needs to cover more than human administrator passwords. Local Fortinet administrators, VPN users, API accounts, service accounts, LDAP and RADIUS bind accounts, TACACS+ secrets, SAML-related credentials, shared accounts, and any reused credentials on adjacent edge devices should be rotated where exposure is plausible. If packet capture or traffic inspection occurred, downstream application credentials may also need review. Treating this as a single admin password reset can leave the real blast radius untouched.

Management exposure is another core issue. Fortinet recommends trusted hosts as a baseline, local-in policy as a stronger control, and removal of internet administration as the preferred end state. That hierarchy is correct. Internet-facing firewall administration creates a public test surface for credential abuse. Even with MFA, every exposed login endpoint becomes an opportunity for enumeration, spraying, social engineering follow-up, and future vulnerability exploitation. Admin access should be reachable through controlled management networks, jump hosts, VPN paths with strong MFA, and explicit source restrictions.

This incident also fits a broader pattern. Perimeter appliances have become high-value identity targets, not just vulnerability targets. Attackers do not always need a new exploit if they can reuse credentials from an old one. They do not need malware on an endpoint if a firewall hands them remote access. They do not need to decrypt the whole network if the gateway already sees enough traffic to collect the next set of secrets. FortiBleed shows how yesterday’s breach data, today’s exposed management interface, and legacy password storage can combine into a current intrusion path.

The name makes the campaign sound like a single wound. The real problem is more structural. Many organizations still operate perimeter devices as static infrastructure, patched on a schedule and checked during audits, rather than as identity-bearing systems that need continuous credential rotation, configuration drift review, management-plane isolation, and telemetry. A firewall is not just a box that filters traffic. It is a privileged identity system with routes, secrets, sessions, and trust relationships attached to it.

For Fortinet customers, the near-term answer is clear: terminate sessions, rotate credentials, confirm MFA, upgrade to supported FortiOS branches, force PBKDF2 migration, remove legacy hashes, review logs, compare configurations, and restrict management access. For any environment with signs of unauthorized configuration changes, unexpected accounts, suspicious VPN activity, or packet capture use, treat the appliance as compromised and investigate internal movement from that point forward.

---

How Can Netizen Help?

Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.

---