← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2025-22275 · CWE-532 · Disclosed 2025-01-03

iTerm2 3

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is less a front-door break-in than a note accidentally left on the shared kitchen counter

CVE-2025-22275 is an information leak in iTerm2 3.5.6 through 3.5.10, fixed in 3.5.11 on January 2, 2025. Under specific it2ssh or SSH Integration configurations, iTerm2 logs terminal input and output to /tmp/framer.txt on the remote host, where other users on that host may be able to read it. The vendor says this occurs when the affected iTerm2 versions are used with SSH integration and the remote host has Python 3.7+ in the default path.

The vendor's CRITICAL 9.3 rating badly overstates enterprise risk because this is not an unauthenticated internet-facing remote exploit in the way the CVSS vector implies. In practice, the attacker usually needs access to the same remote system where the victim SSHs, plus a configuration niche that many fleets never use; the real risk is credential and command leakage on shared bastions, jump boxes, and multi-user Unix hosts, not mass remote compromise.

"Critical on paper, but real-world abuse usually starts after the attacker already has a foothold on the SSH host."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land on the same remote Unix host the victim uses

The attacker first needs a foothold on a host that an affected iTerm2 user connects to with it2ssh or SSH Integration enabled. The practical weapon here is ordinary ssh, not an exploit framework; this CVE does not create initial access by itself.
Conditions required:
  • Attacker has authenticated access or equivalent execution on the remote host
  • Victim uses iTerm2 3.5.6-3.5.10
  • Victim connects with it2ssh or the SSH profile/integration path described by the vendor
Where this breaks in practice:
  • This is already post-initial-access for most enterprises
  • Many environments do not use iTerm2's SSH integration at all
  • Single-user remote hosts eliminate the cross-user read angle
Detection/coverage: Vulnerability scanners can flag the client version on managed macOS endpoints, but they generally will not prove the risky SSH Integration path was used against a given remote host.
STEP 02

Abuse the leaked remote-side transcript file with cat or grep

If the vulnerable path executed, iTerm2 may have written session input/output to /tmp/framer.txt on the remote system. The attacker can then use basic tools like cat, tail, or grep to read terminal content without needing a specialized PoC.
Conditions required:
  • /tmp/framer.txt exists on the remote host
  • The file permissions permit read access to the attacker
  • The file has not already been rotated, cleaned, or deleted
Where this breaks in practice:
  • The file is only created in the affected workflow
  • Permissions and tmp cleanup policies may block or erase evidence
  • Some fleets mount /tmp with restrictive defaults or aggressive cleanup
Detection/coverage: EDR or audit tooling on shared Linux/Unix servers may catch reads of /tmp/framer.txt; network scanners will miss this entirely.
STEP 03

Extract useful secrets from terminal traffic

The attacker parses the transcript for credentials, API keys, pasted tokens, internal hostnames, commands, and sensitive command output. Commodity text tools like grep, awk, and strings are enough because the data is already plain text.
Conditions required:
  • Sensitive material was typed or displayed in the recorded session
  • Captured tokens or outputs are still valid and meaningful
Where this breaks in practice:
  • Good operator hygiene reduces exposure if secrets are not pasted or echoed
  • Short-lived tokens, MFA, and just-in-time credentials sharply reduce follow-on value
Detection/coverage: There is no signature-level exploit artifact beyond access to the file; this is mostly a data exposure and secret-harvesting detection problem.
STEP 04

Pivot with harvested credentials

Any recovered secrets can then be reused for lateral movement, cloud API access, or privileged Unix operations. The CVE's real damage depends on what the victim exposed in-session, not on the bug itself.
Conditions required:
  • Recovered secrets map to reachable downstream systems
  • Credential controls do not block replay or reuse
Where this breaks in practice:
  • MFA, PAM controls, token binding, and rapid rotation often break the chain
  • Blast radius is bounded to what appeared in the captured sessions
Detection/coverage: Downstream identity telemetry, PAM logs, cloud audit trails, and EDR are more likely to show the attacker than the original iTerm2 flaw.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation located in the sources reviewed; not KEV-listed per user-supplied intel and no CISA listing was found during review.
Proof-of-concept availabilityNo meaningful exploit kit is required. Abuse is basically cat /tmp/framer.txt after the attacker already has access to the remote host.
EPSSUser-supplied EPSS is 0.00132 (~0.132%), which is extremely low and consistent with a niche, low-scale exploitation pattern.
KEV statusNo. Not present in the reviewed CISA KEV materials; no known KEV add date.
CVSS vector reality checkCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N treats this like direct network-reachable compromise. That is a bad fit: real abuse usually requires shared remote-host access and a specific iTerm2 SSH workflow.
Affected versionsiTerm2 3.5.6 through 3.5.10, plus beta versions of 3.5.6 and later called out by the vendor.
Fixed version3.5.11. OSV also maps the affected range to introduced 3.5.6 and fixed 3.5.11.
Exposure footprintThis is a client-side macOS terminal emulator issue, not a server daemon or internet-listenable service. Shodan/Censys-style external exposure is basically not the right model here.
Exploit prerequisitesVendor says both conditions must hold: the victim used it2ssh or the SSH-profile/integration path, and the remote host had Python 3.7+ in the default search path.
Disclosure and attributionPublished 2025-01-03. The public write-up is vendor-authored in iTerm2 release notes; no separate external researcher credit was identified in the reviewed sources.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.5/10)

The decisive downgrading factor is attacker position: this bug usually matters only after the attacker already has access to the same remote Unix host the victim is using. That makes it a targeted post-foothold secret exposure problem with real consequences on shared bastions, but it is not a fleet-wide unauthenticated remote compromise event.

HIGH Affected version range and fix version
HIGH Exploit preconditions from vendor advisory
MEDIUM Real-world severity downgrade from vendor CVSS

Why this verdict

  • Requires a prior foothold on the remote host: the attacker generally needs authenticated access or code execution on the same Unix system where the victim's SSH session lands, which is strong downward pressure from the vendor's 9.3 baseline.
  • The reachable population is narrow: exploitation depends on it2ssh or a specific SSH Integration configuration, affected iTerm2 versions, and Python 3.7+ on the remote host. That sharply reduces exposed enterprise population versus a normal network service bug.
  • Impact is meaningful but bounded: this can leak commands, outputs, and secrets, especially on shared bastions, but it does not directly give code execution, persistence, or broad unauthenticated access by itself.

Why not higher?

This is not a clean pre-auth internet exploit, and the CVSS vector overstates that badly. The chain assumes a prior compromise stage or legitimate access on the SSH destination plus a niche feature path, so it does not justify a HIGH or CRITICAL fleet posture for most enterprises.

Why not lower?

It is still more than hygiene-level noise because the leaked material can include real credentials, pasted secrets, internal hostnames, and privileged command output. On shared Unix infrastructure, one stray /tmp/framer.txt can hand an already-present attacker the exact data needed for lateral movement.

05 · Compensating Control

What to do — in priority order.

  1. Delete /tmp/framer.txt on shared SSH hosts — Hunt for and remove the remote artifact on bastions, jump boxes, build hosts, and other multi-user Unix systems touched by macOS engineers. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this cleanup is fast and immediately cuts residual exposure.
  2. Disable risky SSH integration paths where feasible — Temporarily stop using it2ssh or profile-driven SSH Integration on shared remote hosts if you cannot verify patch uptake quickly. For MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window; use this selectively on high-value admin populations rather than as a broad emergency change.
  3. Shorten the value of leaked secrets — Prioritize short-lived tokens, MFA-backed SSH access, and rapid rotation for credentials likely to have appeared in terminal sessions. That does not fix the bug, but it reduces the usefulness of anything harvested from /tmp/framer.txt; again, no mitigation SLA — go straight to the 365-day remediation window.
  4. Watch reads of the artifact on shared Unix systems — Add a simple file-access watch or EDR analytic for /tmp/framer.txt reads, especially by unexpected users or service accounts. There is no mitigation SLA for a MEDIUM under noisgate, but this gives you a cheap tripwire while patching catches up.
What doesn't work
  • A perimeter scanner or external ASM platform will not help much; this is not an internet-facing daemon exposure problem.
  • WAFs and network IPS are irrelevant because the vulnerable behavior is a client-side SSH workflow that writes data to a file on the remote host.
  • Patching only the remote Unix host does not fix the source bug; the vulnerable component is iTerm2 on macOS, though remote-side cleanup is still necessary.
06 · Verification

Crowdsourced verification payload.

Run this on the managed macOS endpoint where iTerm2 is installed, not on the remote SSH server. Invoke it as bash check_iterm2_cve_2025_22275.sh with a standard user account; no root is required. It checks the installed iTerm2 version against the known affected range and reports VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_iterm2_cve_2025_22275.sh
# Detects whether the local macOS host has an iTerm2 version in the affected range
# for CVE-2025-22275 (3.5.6 through 3.5.10, fixed in 3.5.11).
#
# Exit codes:
#   0 = PATCHED / not affected
#   1 = VULNERABLE
#   2 = UNKNOWN / could not determine

set -u

APP_PATHS=(
  "/Applications/iTerm.app"
  "$HOME/Applications/iTerm.app"
)

find_iterm() {
  local p
  for p in "${APP_PATHS[@]}"; do
    if [ -d "$p" ]; then
      echo "$p"
      return 0
    fi
  done
  return 1
}

normalize_version() {
  # Keep first three numeric components; pad missing pieces with zeros
  local v="$1"
  local major minor patch
  v="${v%%[^0-9.]*}"
  IFS='.' read -r major minor patch _rest <<< "$v"
  major=${major:-0}
  minor=${minor:-0}
  patch=${patch:-0}
  echo "$major.$minor.$patch"
}

ver_ge() {
  # returns 0 if $1 >= $2
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | tail -n1)" = "$1" ]
}

ver_lt() {
  # returns 0 if $1 < $2
  [ "$1" != "$2" ] && [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}

APP_PATH="$(find_iterm)"
if [ -z "${APP_PATH:-}" ]; then
  echo "PATCHED: iTerm2 not found in standard locations; this host is not affected by CVE-2025-22275 via local iTerm2."
  exit 0
fi

PLIST="$APP_PATH/Contents/Info.plist"
if [ ! -f "$PLIST" ]; then
  echo "UNKNOWN: Found iTerm2 at '$APP_PATH' but could not locate Info.plist."
  exit 2
fi

RAW_VER="$(/usr/bin/defaults read "$PLIST" CFBundleShortVersionString 2>/dev/null || true)"
if [ -z "$RAW_VER" ]; then
  echo "UNKNOWN: Could not read CFBundleShortVersionString from '$PLIST'."
  exit 2
fi

VER="$(normalize_version "$RAW_VER")"
AFFECTED_START="3.5.6"
FIXED_VER="3.5.11"

if ver_ge "$VER" "$AFFECTED_START" && ver_lt "$VER" "$FIXED_VER"; then
  echo "VULNERABLE: iTerm2 version $VER is within the affected range for CVE-2025-22275."
  echo "NOTE: This check validates the local vulnerable client version only; remote-host artifact cleanup (e.g. /tmp/framer.txt) must be assessed separately."
  exit 1
fi

if ver_ge "$VER" "$FIXED_VER"; then
  echo "PATCHED: iTerm2 version $VER is fixed for CVE-2025-22275."
  exit 0
fi

if ver_lt "$VER" "$AFFECTED_START"; then
  echo "PATCHED: iTerm2 version $VER is older than the known affected range for CVE-2025-22275."
  exit 0
fi

echo "UNKNOWN: Unable to classify iTerm2 version '$RAW_VER' (normalized: '$VER')."
exit 2
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as a targeted macOS engineer/admin endpoint issue, not a perimeter fire. Inventory iTerm2 on managed Macs, identify users on 3.5.6-3.5.10, and immediately sweep shared bastions/jump hosts for /tmp/framer.txt; because this is a MEDIUM reassessment there is no noisgate mitigation SLA — go straight to the 365-day remediation window, but you should still do the remote-file cleanup opportunistically now. Finish the actual upgrade to 3.5.11+ for remaining affected Macs within the noisgate remediation SLA of 365 days, with bastion users, SREs, and privileged admins first in line.

Sources

  1. iTerm2 3.5.11 release notes / security fix
  2. iTerm2 downloads page with 3.5.11 advisory text
  3. iTerm2 Shell Integration documentation
  4. Official CVE JSON record
  5. NVD entry
  6. OSV entry with introduced/fixed mapping
  7. CISA Known Exploited Vulnerabilities Catalog
  8. FIRST EPSS overview
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.