TL;DR: Three severe flaws in legacy Linux services, including an unauthenticated root path in telnetd and two unauthenticated Samba RCEs, one of which had likely existed for about 25 years, were found by SafeBreach, showing how decades-old trust assumptions still create modern attack paths. Legacy service exposure is an inventory and privilege-governance problem, not just a patching problem.
At a glance
What this is: SafeBreach's research shows that Telnet and Samba still contain severe legacy attack paths, including unauthenticated remote code execution and local privilege escalation.
Why it matters: It matters because identity and access controls fail quickly when old services trust unauthenticated input, allow shell command construction from client data, or expose privileged execution paths on unmanaged infrastructure.
By the numbers:
- Samba rated both vulnerabilities the maximum possible severity, a CVSS score of 10.0, reflecting that they require no authentication, no user interaction, and can affect any version of the software.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
👉 Read SafeBreach's analysis of unauthenticated RCEs and privilege escalation in legacy Linux services
Context
Legacy Linux services are a governance problem as much as a vulnerability problem. Telnet and Samba were designed under trust assumptions from an earlier era, yet they still sit on servers, printers, network appliances, and other unmanaged assets that many inventories do not fully capture. In this article, the primary issue is not just two CVEs, but the persistence of privileged execution paths that accept unauthenticated or weakly controlled input.
The identity angle is direct: when a service can inherit environment variables, build shell commands from client data, or execute with elevated rights, access control becomes part of the attack surface. That is why NHI governance, secrets handling, and privilege containment matter even in a story about old Linux daemons. The starting position here is unfortunately typical, not exceptional, for long-lived infrastructure that was never designed for zero trust.
Key questions
Q: What breaks when legacy services accept untrusted input before authentication?
A: Authentication can be bypassed, privilege boundaries can collapse, and helper processes may inherit attacker-controlled state. In practice, that means a service can turn a local or remote input channel into root-level execution if it was designed to trust environment variables, RPC parameters, or shell-formatted commands from unauthenticated callers.
Q: Why do old Linux services still create modern privilege escalation risk?
A: Age does not remove risky design assumptions. Legacy daemons often predate modern trust segmentation, so they may expose command execution, environment inheritance, or unauthenticated service logic that newer systems would not permit. That makes them especially dangerous when they remain reachable on unmanaged infrastructure.
Q: How can security teams tell whether a fix actually reduced exposure?
A: They should test whether the original attack outcome can still be reproduced after remediation. If the same-scope retest cannot achieve the same impact, the fix has evidence behind it. If it can, the programme has only documented activity, not reduction.
Q: Who is accountable when a critical remote access service grants unauthenticated root access?
A: Accountability sits with the team that owns the service exposure, the patching decision, and the retirement plan for the legacy path. Security, infrastructure, and platform owners all have a role, but no single control compensates for leaving a root-capable service reachable from untrusted networks.
Technical breakdown
How telnetd turned an environment variable into root access
The telnetd flaw came from a trust boundary failure between an unauthenticated network session and a privileged local login process. Telnetd accepted client-controlled environment variables before authentication, then passed them to /usr/bin/login, which interpreted CREDENTIALS_DIRECTORY as a legitimate systemd credential source. Because login trusted that variable without verifying its origin, an attacker could point it at a directory containing login.noauth and bypass authentication. This is a design flaw, not a buffer overflow: the code does exactly what it was told to do, but from the wrong trust domain.
Practical implication: remove unauthenticated environment-variable passthrough from privileged service-to-service handoffs.
Why shell command construction in Samba creates RCE risk
Samba exposes RPC-driven service workflows for printing and other Windows-style functions, and some paths assemble shell commands from client-supplied parameters. When a service formats untrusted input into a command line, quoting alone is not enough if the input can break the intended structure or reach a different code path. The two discovered flaws show the same pattern in different subsystems: a legacy service delegates work to shell commands, but the input validation is inconsistent and incomplete across function boundaries. That is why unauthenticated remote code execution can survive for years in mature software.
Practical implication: eliminate shell command construction from client-facing RPC paths wherever possible.
Why legacy services remain dangerous even after partial fixes
The telnetd case also shows why narrow patches often leave residual exposure. One fix removed the abused variable, but the broader issue remained because unauthenticated clients could still influence privileged process state. The later comprehensive fix changed the acceptance model itself by restricting arbitrary environment variables. That difference matters across identity and access systems too: if the service boundary is still trusting data from an untrusted caller, attackers will keep looking for alternate control channels. Old code paths do not become safe because they are old or because one symptom was patched.
Practical implication: review the trust model, not just the specific CVE, before declaring legacy exposure closed.
Threat narrative
Attacker objective: The attacker objective is to gain privileged execution on legacy Linux services that were assumed to be low-risk or already secured by age and familiarity.
- Entry occurs through unauthenticated access to legacy network services or a local user context on systems running telnetd or Samba.
- Credential or execution abuse follows when attacker-controlled variables or RPC parameters are passed into privileged logic or shell commands without robust sanitization.
- Impact is root-level access or unauthenticated remote code execution on widely deployed systems, enabling full host compromise and lateral movement.
Breaches seen in the wild
- Gladinet Hard-Coded Keys RCE Exploitation — Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
- MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Legacy service trust is an identity problem, not just a vulnerability problem. The core failure in this research is not age alone, but the way privileged daemons continue to trust unauthenticated or weakly controlled input. When a service accepts environment variables, RPC parameters, or shell-formatted commands from outside its trust boundary, access control collapses before authentication even begins. For identity teams, that is a reminder that service accounts, credential channels, and execution context all need governance. The practical conclusion is to treat legacy service trust boundaries as first-class identity surfaces.
Partial CVE fixes often preserve the original attack surface. The telnetd example shows how a narrow patch can remove one abuse path while leaving the broader delegation model intact. That leaves organisations with a false sense of closure, especially when the patched component still processes attacker-controlled state in a privileged process. This pattern is common in older infrastructure where hardening is layered onto outdated architecture. Practitioners should assume that if the trust model was not changed, the residual risk likely remains.
Weak inventory is what lets legacy attack paths survive. Telnet and Samba are still present on devices that many organisations do not track well, including printers and appliances. That creates a governance gap between the vulnerability scanner, the asset inventory, and the actual attack surface. The named concept here is legacy privilege blind spot: privileged services that remain reachable because they are hidden in unmanaged infrastructure or forgotten code paths. The operational conclusion is to inventory by service behaviour, not just by server name.
Unauthenticated RCE on infrastructure services raises the blast radius of everything downstream. A flaw in a file-sharing or remote-access service is rarely isolated to one host if the same service class exists across fleets, appliances, and embedded systems. That makes segmentation, exposure reduction, and hard dependency removal more important than reactive patching alone. In frameworks such as MITRE ATT&CK and NIST SP 800-53, this maps directly to credential access, lateral movement, and control of externally exposed services. The practitioner takeaway is to treat legacy protocol exposure as an enterprise risk multiplier.
Security teams need to stop equating maturity with safety. Services that have existed for decades often carry unexamined assumptions about trust, authentication, and command execution. That makes them attractive not because they are new, but because defenders stop reviewing them with the same rigor applied to newer AI, cloud, or application stacks. The broader governance lesson is that long-lived software can hide the most consequential control failures precisely because it feels familiar. The right response is continuous scrutiny, not historical confidence.
From our research:
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
- From our research: The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
- Legacy service exposure behaves like hidden identity debt, so readers should also review 52 NHI Breaches Analysis for recurring trust failures across compromised credentials and service access.
What this signals
Legacy Linux services are the kind of hidden exposure that becomes visible only after a breach or a targeted research effort. For identity and security programmes, the signal is that attack surface management must extend beyond cloud and SaaS assets into unmanaged infrastructure, where old trust assumptions and weak service ownership persist.
Legacy privilege blind spot: services that still accept unauthenticated input into privileged execution paths will keep outliving the controls designed to protect them. Teams should align this with OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls to make exposure reduction and account hygiene measurable.
The practical lesson for programmes is to build a retirement path for obsolete protocols before the next discovery. That means explicit ownership, verified exposure, and enforced migration away from Telnet-like access patterns and any service that still executes shell commands from client data.
For practitioners
- Inventory legacy service exposure across unmanaged assets Find Telnet and Samba instances on servers, appliances, printers, and embedded systems, then map which ones are reachable from untrusted networks. Prioritise any device that does not appear in standard asset inventories but still exposes remote administration or file-sharing services.
- Remove arbitrary environment-variable passthrough from privileged services Review daemons that launch helper processes as root and block unauthenticated callers from setting environment variables that influence authentication or execution. Any control channel that can alter a privileged process should be explicitly allow-listed and tested for alternate credential paths.
- Eliminate shell command construction from client-facing RPC paths Replace shell-formatted command execution with safe API calls or tightly constrained argument handling in printing, file-sharing, and remote management workflows. Where shell usage cannot be removed immediately, isolate the service and treat the code path as high risk.
- Segment legacy protocols away from general user traffic Restrict Telnet and Samba to management networks or tightly scoped host groups, and block access from printer, appliance, and workstation segments that do not require them. Network controls do not fix the flaw, but they reduce exposure while remediation is underway.
- Test patch completeness, not just patch presence Validate whether a fix changed the trust model or only removed a single abusive input. If the service still accepts attacker-controlled state in a privileged context, assume additional paths remain until source review or targeted testing proves otherwise.
Key takeaways
- Legacy Linux services can still deliver root access or remote code execution when they trust unauthenticated input too far inside the privilege boundary.
- This research found one telnetd privilege escalation path and two Samba RCEs, including code that had likely gone unexamined for about 25 years.
- The control that matters most is not just patching, but removing arbitrary trust in privileged service inputs and shrinking exposure on unmanaged infrastructure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006 , Credential Access; TA0008 , Lateral Movement; TA0040 , Impact | The article describes unauthenticated access, privilege escalation, and host compromise. |
| NIST CSF 2.0 | PR.AC-4 | Legacy service exposure and privilege handling are access-control issues. |
| NIST SP 800-53 Rev 5 | AC-6 | The breaches exploit excessive privilege in service execution paths. |
| CIS Controls v8 | CIS-5 , Account Management | Unchecked service accounts and legacy helpers create hidden privilege paths. |
| OWASP Non-Human Identity Top 10 | NHI-03 | The telnetd issue mirrors secret or credential trust failures in non-human identity flows. |
Map exposed legacy services to credential access and lateral movement paths, then contain them with segmentation and hardening.
Key terms
- Legacy Privilege Blind Spot: A legacy privilege blind spot is a service or device that still runs with elevated trust but sits outside normal ownership, inventory, or review. These blind spots persist when organisations track servers but not service behaviour, allowing old execution paths to remain reachable long after the software should have been retired.
- Unauthenticated Trust Boundary: An unauthenticated trust boundary is the point where a service accepts input before verifying identity or authorisation. When that boundary feeds privileged logic, the attacker does not need to steal a credential first. They can use the service itself to carry untrusted data into root-level or high-impact operations.
- Shell-formatted Command Execution: Shell-formatted command execution occurs when software builds a command line as text and passes it to a shell or shell-like interpreter. If any part of that command comes from a client, configuration value, or environment variable, injection risk rises sharply because quoting and escaping often fail across all code paths.
- Credential Inheritance Channel: A credential inheritance channel is a mechanism that passes authentication-related state from one process to another, such as an environment variable or temporary secret directory. These channels are useful only when origin is trusted and controlled. If an attacker can influence them, they can redirect or bypass privileged authentication logic.
What's in the full report
SafeBreach's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step exploitation logic for the telnetd CREDENTIALS_DIRECTORY path and the exact conditions that made root access possible.
- Code-level analysis of the Samba SAMR and print-server RCE paths, including the string handling and command formatting failures.
- Vendor patch timeline details showing how the fixes evolved from narrow symptom removal to broader trust-model changes.
- Researcher notes and demonstrations that show how the proof-of-concept paths were validated in practice.
👉 SafeBreach's full blog covers the telnetd root path, the Samba RCE chains, and the patch history.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and identity lifecycle controls. It gives practitioners a practical baseline for reducing privilege sprawl across both human and non-human access models.
Published by the NHIMG editorial team on August 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org