VPN Exploits: What an External Pentest Catches First

An external network pentest perimeter devices review answers a question vendor patches and scanners cannot. On 8 June 2026, CISA added CVE-2026-50751, a CVSS 9.3 authentication bypass in a widely deployed Check Point VPN gateway, to its Known Exploited Vulnerabilities catalog with a three-day federal remediation deadline. Researchers at watchTowr Labs noted that “this vulnerability has been exploited in the wild since 7th May 2026”, roughly a month before the vendor patch was available. The same week, Censys published the FortiBleed advisory, identifying “roughly 73,932 unique firewall URLs across 194 countries” leaking credentials from internet-facing Fortinet appliances. For CISOs running edge VPN and firewall infrastructure, the message is simple: vendor patches and scanners alone are not catching this.

The Verizon 2026 Data Breach Investigations Report found that 31% “of breaches now start with software vulnerabilities, beating stolen passwords as the top way attackers get in”. That is a structural change in how organisations are compromised, and unpatched or misconfigured perimeter appliances are the single largest contributor.

Why VPN Appliances Are the Favourite Initial-Access Vector Right Now

Edge appliances sit on the public internet, terminate authentication, hold privileged certificates, and bridge directly into the internal network. Three properties make them disproportionately attractive to ransomware affiliates and intrusion brokers.

• They are always exposed. Unlike an internal application that an attacker has to reach laterally, a VPN portal answers on port 443 from anywhere in the world.
• They are slow to patch. Edge devices often sit behind change-control windows because a bad patch interrupts remote access for the entire workforce. The CVE-2026-50751 timeline (exploited 7 May, patched in early June, KEV-listed 8 June) is typical, not exceptional.
• A single foothold is enough. Once an attacker authenticates to the VPN, they are inside the corporate network with the same access a remote employee would have.

A scheduled VPN gateway security assessment maps this exact surface as part of a broader external network pentest. It is not the same activity as running a vulnerability scanner against the appliance IP and reading the CVE output.

Six Things a Human-Led External Pentest Checks That Scanners Cannot

Scanners are good at one thing: matching observed banners and behaviours against a database of known CVEs. That is useful, and the CTDefense team runs scanners as part of every engagement. The work that follows is what a CVE scanner cannot do, and what the vulnerability scanner vs penetration test comparison really turns on.

• Version correlation across shadow assets. Most CMDBs are incomplete. The CTDefense team uses passive DNS, certificate transparency logs, and active subdomain enumeration to surface internet-facing appliances the security team did not know it owned, then fingerprints software versions against known-exploited CVE corpora. Internet-facing attack surface enumeration is the practical name for this step, and it almost always finds at least one forgotten device.
• Certificate validation logic. Many VPN gateways will accept client certificates with weak issuer chains, expired intermediates, or wildcard scopes that were never meant to validate against the production trust store. The team tests the logic, not just the cert presence.
• Credential-stuffing the VPN portal. When advisories like FortiBleed identify leaked credential corpora, the team checks whether any of the leaked usernames or password fragments resolve to a client’s portal and whether rate-limiting and lockout actually trigger. Credential stuffing VPN portal testing is rule-bound (no live account compromise without scope sign-off), but it is the only way to know if MFA gaps or default service-account credentials leave the front door open.
• Subdomain takeover on forgotten DNS records. A dangling CNAME pointing to a deprovisioned cloud bucket or expired SaaS tenancy lets an attacker host content under the client’s own domain. The team enumerates DNS, looks for dangling records, and confirms takeover paths without actually claiming the resource.
• Exposed admin interfaces on non-standard ports. Edge appliance vendors document the canonical management ports; attackers (and the team) scan the full range, because firewall rules often miss the alternate ones (TCP 8443, 4443, 10443, 9443).
• Authentication and session logic at the protocol layer. IKEv1 aggressive mode, NTLM relay against the VPN’s identity provider, fallback to weaker authentication when SAML fails. These are protocol-level findings a scanner banner-match will not surface.

Shadow Assets: The Perimeter Devices That Don’t Appear in Your CMDB

If a CISO asks the team “what does an external network pentest actually test”, the most honest answer starts here. The first deliverable of any external engagement is an enumerated asset list, and that list is almost always longer than the one the client provided at scoping.

In recent CTDefense engagements, shadow assets typically include:

• A staging environment spun up for a migration and never decommissioned.
• A subsidiary’s appliance pointed at a corporate DNS record after an acquisition.
• A test VPN concentrator left running by a third-party integrator.
• An old firewall pair that was supposed to be replaced but is still answering on a secondary IP.

Each one of these carries a software version, a patch lag, and a credential set that the central security team is not tracking. As covered in what attackers find on a typical enterprise perimeter, the shadow-asset finding is the one that most often leads to a high-severity recommendation.

Certificate Validation and Credential-Reuse: The Manual Testing Layer

A perimeter scan tells the client which CVEs apply to which boxes. A human-led external pentest answers the harder question: given the client’s specific configuration, identity provider, and credential exposure, can an attacker actually authenticate?

The team works through a defined sequence on each in-scope appliance:

• Certificate chain review. Manual validation of the trust store, intermediate validity windows, and pinning behaviour. The team checks whether expired or self-signed certificates are silently accepted, and whether SAML or OIDC integrations downgrade when a primary handler fails.
• Credential exposure correlation. Usernames and email patterns from the client’s domain are checked against published infostealer corpora and breach aggregations. The team does not handle the underlying credential material; it reports which accounts appear and recommends forced rotation.
• Controlled portal testing. With written scope approval, the team sends a small number of authentication attempts against the live portal to confirm whether lockout, alerting, and MFA enforcement behave as the security team believes they do.

The watchTowr finding that CVE-2026-50751 had been exploited for a month before the patch landed answers a common buyer question, namely how long after a patch is released are companies still exploited. The window opens before the patch, not after it. Patch-cadence reporting captures none of it. Active testing during that window is the only thing that does.

What to Do Before the Next KEV Alert Drops

The next CISA KEV listing on a perimeter appliance is a matter of when, not whether. Organisations subject to NIS2 external network security testing obligations under Article 21 are under regulatory pressure to demonstrate that their perimeter posture has been independently verified, not just patched on schedule. The same applies to PCI DSS and DORA-aligned testing programmes.

A few concrete steps the CTDefense team recommends to clients in the days after a KEV listing on edge infrastructure:

• Inventory before scanning. A scan against an incomplete asset list is worse than no scan. Reconcile the CMDB against passive DNS and certificate transparency before any vendor-specific check.
• Test the authentication path, not just the patch status. Confirm MFA is enforced on the portal, that fallback authentication has the same controls as primary, and that session policies expire idle connections.
• Rotate credentials that appear in public exposure feeds. Forced rotation is faster and cheaper than incident response after the fact.
• Schedule independent testing on a meaningful cadence. Annually is the minimum for a perimeter that does not change. After every significant change (a new VPN deployed, a firewall upgraded, a subdomain added, an acquisition closed) is the working answer to how often should an external pentest be run.
• Document the methodology, not just the findings. A board or regulator wants to see what was tested, how, and against which threat-actor playbooks. This is also what differentiates a real third-party security assessment from a checklist exercise.

CTDefense continues to support mid-to-large enterprises in finance, healthcare, manufacturing, and critical infrastructure with External Network Security Audit engagements that map exposed perimeter devices, validate authentication and certificate logic, and correlate findings against current threat-actor activity. Organisations running Check Point, Fortinet, or other edge appliances on the public internet are encouraged to commission an external review before the next KEV listing arrives, not after. The window between exploitation and patch is where the loss happens; testing during that window is what closes it.