Organizations using Ivanti Connect Secure face active attacks against two newly identified weaknesses. One can support privilege escalation for a local authenticated attacker, while the other can let a remote authenticated attacker place controlled content at a known disk location. The weaknesses can be chained with a previously reported code-execution issue. The combined risk has been rated high.
What Happened
Multiple vulnerabilities have been identified in Ivanti Connect Secure, and two of them are being exploited in the wild. The security bulletin rated the overall risk high because the weaknesses can be used together and may also be chained with an earlier remote code-execution issue.
CVE-2026-111357 is described as a missing-authentication weakness affecting a critical function. The bulletin says a local authenticated attacker could use it to escalate privileges. CVE-2026-118527 involves predictable numbers or identifiers and can allow a remote authenticated attacker to upload files containing attacker-controlled content to a known location on disk. These two weaknesses can be chained with CVE-2026-104935, which had previously been covered as a remote code-execution vulnerability.
The evidence confirms active exploitation of the two newly listed weaknesses but does not provide a complete attack chronology, affected-version table, victim count, or description of confirmed outcomes in specific organizations. It does establish that remediation is no longer a routine patching exercise. Organizations need to treat affected appliances as potentially exposed to real attack activity and consult the vendor’s details for applicable versions and fixes.
Why It Matters
Ivanti Connect Secure provides remote connectivity, placing it on an important trust boundary between users and internal resources. A weakness that raises privileges or writes attacker-controlled content to disk can become more serious when combined with another weakness that enables code execution. The high-risk rating reflects that combined path rather than viewing each issue in isolation.
Active exploitation changes the decision. Teams cannot assume that applying a fix at the next normal maintenance window will be sufficient. They also need to consider whether an affected system was targeted before remediation. Patching closes the known weakness, but it does not by itself establish that the device was never accessed or changed.
The exposure matters to any organization relying on these systems for workforce, administrator, or partner access. A compromised remote-access platform may give attackers a position from which they can seek additional privileges or reach connected resources. The source does not confirm those downstream outcomes in specific victims, but the available capabilities justify an urgent response.
What to Watch
Watch for updated vendor information defining the affected releases, available fixes, and any additional detection or recovery guidance. Organizations should also monitor whether investigations identify a common chain involving the two actively exploited weaknesses and the previously reported code-execution issue.
Internally, watch for unexplained file placement, privilege changes, data manipulation, or other activity around the appliance. Those indicators would require deeper investigation. Absence of a public victim count should not be interpreted as absence of risk, because exploitation in the wild is already confirmed.
What Defenders Should Do
Immediate action: identify every Ivanti Connect Secure deployment, determine whether it falls within the vendor’s affected range, and apply the vendor-issued fixes. Prioritize systems that are reachable by remote users or support sensitive access paths. If an update cannot be applied immediately, reduce unnecessary reachability and access while preparing the fix, recognizing that restriction does not replace patching.
Investigation: review available appliance, authentication, file, and administrative records for activity that does not match expected operations. Focus on suspicious privilege elevation, unexpected content written to disk, unusual authenticated access, and signs that the earlier code-execution weakness may have been used as part of a chain. Preserve relevant records before disruptive remediation where possible.
Access control: review local and remote authenticated accounts associated with the system. Remove access that is no longer required, validate privileged roles, and address credentials or sessions if the investigation finds evidence of misuse. Because the disclosed weaknesses include paths available to authenticated attackers, valid access should not automatically be treated as trusted behavior.
Recovery decision: if evidence suggests the system was compromised, do not treat patch installation as the end of the incident. Escalate to the organization’s response process and assess connected systems according to the access the appliance provided. Keep leadership informed about both patch status and investigation status because those are different measures of risk.
The Larger Lesson
Security teams should assess exploit chains, not only individual severity labels. A privilege weakness, a predictable identifier, and a file upload path may appear limited when reviewed separately. Combined with a code-execution issue, they can create a much more consequential route through a trusted access system.
The durable lesson is to treat remote-access infrastructure as a high-priority control plane. Fast patching matters, but so do asset visibility, restricted access, useful logging, and the ability to investigate what happened before the fix was installed.