# The Attack Surface Crisis: Why 60% of Organizations Leave Admin Panels Exposed to the Internet
The cybersecurity industry has spent years focused on patching—but a sweeping analysis of 3,000 organizations reveals a more fundamental problem. Most companies don't need faster patch cycles. They need to stop exposing services to the internet that should never have been there in the first place. According to Intruder's 2026 Attack Surface Management Index, six in ten organizations currently operate with exposed HTTP admin panels, half have risky ports accessible from the public internet, and 42% have databases directly reachable by anyone. As time-to-exploit windows collapse to a single day, the question is no longer just "Can we patch faster?" It's become "Why was this exposed at all?"
## The Threat Landscape Has Shifted
Vulnerability patching was always part of the defense equation, but it has never been the whole solution. A critical zero-day like MongoBleed—which allowed unauthenticated attackers to pull credentials and session tokens directly from server memory—demonstrates the stakes. When such a vulnerability drops, the clock starts immediately. Organizations that have exposed MongoDB instances, or any internet-facing database, face a race against adversaries who are already scanning the internet for those services.
But here's the uncomfortable reality: most of the organizations hit hardest in 2026 weren't compromised through zero-days. They were compromised through services that should have been isolated from the internet entirely. An exposed MySQL database can be brute-forced. An accessible RDP service can be credential-guessed. A publicly discoverable API documentation site can transform an obscure vulnerability into a well-documented attack path. None of these require exotic exploits—they require only that a service was never meant to be internet-facing in the first place.
This represents a fundamental shift in how modern attacks begin. The narrative of "zero-day vulnerability → patch → security" has been replaced by a simpler, more brutal reality: scan the internet, find exposed services, exploit them. And for many organizations, that second step doesn't require any exploit at all.
## Key Findings: A Breakdown of the Top 10 Exposures
The research analyzed attack surfaces across organizations of varying sizes and industries, identifying which exposures pose the greatest immediate risk:
| Exposure Type | Prevalence | Primary Risk |
|---|---|---|
| MySQL Database Exposed | 26% of organizations | Brute force, credential stuffing, direct data access |
| PostgreSQL Database Exposed | 16% of organizations | Brute force, privilege escalation, data exfiltration |
| API Documentation Exposed | 15% of organizations | Attack path discovery, credential reuse, social engineering |
| WordPress Admin Panel Exposed | 15% of organizations | Brute force, plugin exploitation, website compromise |
| Remote Desktop Service (RDP) Exposed | 11% of organizations | Credential guessing, ransomware initial access, lateral movement |
| SNMP Service Exposed | 9% of organizations | Information disclosure, network reconnaissance |
| phpMyAdmin Exposed | 8% of organizations | SQL injection, direct database manipulation |
| UPnP Service Exposed | 8% of organizations | Device discovery, service fingerprinting, DDoS amplification |
| NTP Service Exposed | 7% of organizations | DDoS amplification, network manipulation |
| RPC Portmapper Exposed | 7% of organizations | Service enumeration, exploitation of legacy systems |
The statistics paint a clear picture: attack surface mismanagement is epidemic. Sixty percent of organizations have at least one HTTP panel exposed. Nearly half have risky ports or services reachable from the internet. Thirty percent have files or information publicly accessible that were never intended to be discoverable.
## Understanding the Exposures: Technical Breakdown
### Databases at the Top
Internet-facing databases represent the single largest class of exposures, occupying the top two spots. MySQL and PostgreSQL each represent tens of thousands of vulnerable installations globally. These aren't theoretical threats—they're actively exploited.
The 2020 PLEASE_READ_ME ransomware campaign compromised over 250,000 MySQL databases using nothing more sophisticated than credential brute-forcing against weak or default passwords. MongoDB and Elasticsearch have faced identical campaigns. The problem is that databases are often configured by operations teams who prioritize accessibility over segmentation, allowing remote connections "just in case" they're needed for maintenance or scaling operations.
The fundamental issue: databases require authentication, but authentication is only effective if credentials are strong and unique. In practice, many exposed databases use default credentials (admin/admin, root with no password) or credentials reused across multiple services.
### Admin Panels and Management Interfaces
WordPress admin panels, phpMyAdmin consoles, and generic HTTP management panels appear on nearly one in three organizations' internet-facing attack surfaces. These are often overlooked because they're not "production" systems—they're management tools, assumed to be internal-use-only.
In reality, they're frequently:
### Legacy Services and Network Tools
SNMP, UPnP, NTP, and RPC portmapper represent an older internet era—services designed for internal network administration, never hardened for public exposure. Yet many organizations find them accessible from the internet, often on cloud infrastructure where network segmentation is assumed but not always implemented.
These services are particularly dangerous because:
### RDP: The Ransomware Gateway
Remote Desktop Protocol appeared at position five, a consistent initial access vector in ransomware campaigns. BlueKeep in 2019 rendered nearly a million RDP-enabled systems immediately exploitable. Even without a zero-day, exposed RDP is a credential-guessing target—and adversaries maintain dictionaries of commonly used credentials (admin/password, administrator/123456).
## The Implications: Who's at Risk and Why It Matters
The impact of attack surface mismanagement is not evenly distributed:
Large enterprises often benefit from mature asset management, regular security assessments, and network segmentation practices. However, they also operate larger attack surfaces with more legacy systems, making complete inventory and remediation more challenging.
Mid-market organizations often have the worst of both worlds: growing infrastructure with immature security practices, limited dedicated security staff, and cloud resources provisioned by developers without security review.
Small organizations frequently lack security expertise entirely, relying on default configurations and hope that "nobody's looking for us" provides sufficient protection.
Critical infrastructure and healthcare organizations face particular pressure: the systems they operate sometimes cannot be taken offline for segmentation work, and legacy medical devices often cannot be patched at all.
The ransomware industry has weaponized these findings systematically. Initial access brokers (IABs) scan the internet for exactly these exposures, then sell access to ransomware operators who use it for entry. A single exposed database can become the entry point for a network-wide compromise costing millions in ransom and remediation.
## Recommendations: Attack Surface Reduction as Foundational Practice
The standard security response—"patch faster"—misses the point. You cannot patch your way out of this problem. Instead, organizations must adopt attack surface reduction as a foundational discipline:
Immediate Actions:
Remediation Strategies:
Organizational Changes:
## HackWire Analysis
What's striking about these findings is how thoroughly they invert the security industry's messaging around vulnerability management. For years, the mantra has been "patch faster, scan deeper, improve your MTTR." Intruder's data suggests that for a meaningful chunk of organizations, the bottleneck isn't patching speed—it's fundamental network design choices made years ago that nobody revisited.
This isn't a technical problem disguised as a process problem. It's a visibility problem. Most organizations don't maintain an accurate, current inventory of what's actually exposed on the internet. Asset discovery happens episodically (after a breach, during compliance audits, when security budgets are approved). By contrast, attackers scan continuously. The asymmetry is brutal.
The secondary finding—that API documentation ranks third in exposures—hints at another pattern: organizations are getting faster at deploying services (microservices, serverless, cloud-native), but not proportionally faster at securing them. Documentation is published, credentials are committed to GitHub, cloud storage buckets are set to public. The velocity of deployment has outpaced the velocity of security review.
For defenders, the message is clear: attack surface reduction is not optional, and it cannot wait for the next major incident or audit cycle. Organizations should treat their internet-facing inventory like they treat their firewall rules—as a set of explicit, documented, regularly reviewed exceptions to a default-deny posture. Everything exposed should have an owner, a business justification, and a compensating control if the exposure cannot be eliminated.
For vendors, this data suggests a market gap: the tooling for *continuous* attack surface discovery and remediation is still immature. Organizations need not just point-in-time scans, but ongoing monitoring that flags new exposures as they're created, integrated into change management workflows.
The uncomfortable truth is that many breaches in 2026 will not be blamed on zero-days or advanced adversaries. They'll be blamed on services that should never have been exposed in the first place, often sitting in plain sight, waiting for someone to notice.
— HackWire Editorial
## Related Coverage