Focus on iterm2 vulnerabilities and metrics.
Last updated: 29 Jun 2025, 22:25 UTC
This page consolidates all known Common Vulnerabilities and Exposures (CVEs) associated with iterm2. We track both calendar-based metrics (using fixed periods) and rolling metrics (using gliding windows) to give you a comprehensive view of security trends and risk evolution. Use these insights to assess risk and plan your patching strategy.
For a broader perspective on cybersecurity threats, explore the comprehensive list of CVEs by vendor and product. Stay updated on critical vulnerabilities affecting major software and hardware providers.
Total iterm2 CVEs: 11
Earliest CVE date: 20 Sep 2017, 20:29 UTC
Latest CVE date: 03 Jan 2025, 05:15 UTC
Latest CVE reference: CVE-2025-22275
30-day Count (Rolling): 0
365-day Count (Rolling): 1
Calendar-based Variation
Calendar-based Variation compares a fixed calendar period (e.g., this month versus the same month last year), while Rolling Growth Rate uses a continuous window (e.g., last 30 days versus the previous 30 days) to capture trends independent of calendar boundaries.
Month Variation (Calendar): 0%
Year Variation (Calendar): -83.33%
Month Growth Rate (30-day Rolling): 0.0%
Year Growth Rate (365-day Rolling): -83.33%
Average CVSS: 1.82
Max CVSS: 10.0
Critical CVEs (≥9): 1
Range | Count |
---|---|
0.0-3.9 | 8 |
4.0-6.9 | 2 |
7.0-8.9 | 0 |
9.0-10.0 | 1 |
These are the five CVEs with the highest CVSS scores for iterm2, sorted by severity first and recency.
iTerm2 3.5.6 through 3.5.10 before 3.5.11 sometimes allows remote attackers to obtain sensitive information from terminal commands by reading the /tmp/framer.txt file. This can occur for certain it2ssh and SSH Integration configurations, during remote logins to hosts that have a common Python installation.
An issue was discovered in iTerm2 3.5.x before 3.5.2. Unfiltered use of an escape sequence to report a window title, in combination with the built-in tmux integration feature (enabled by default), allows an attacker to inject arbitrary code into the terminal, a different vulnerability than CVE-2024-38395.
In iTerm2 before 3.5.2, the "Terminal may report window title" setting is not honored, and thus remote code execution might occur but "is not trivially exploitable."
iTermSessionLauncher.m in iTerm2 before 3.5.0beta12 does not sanitize ssh hostnames in URLs. The hostname's initial character may be non-alphanumeric. The hostname's other characters may be outside the set of alphanumeric characters, dash, and period.
iTermSessionLauncher.m in iTerm2 before 3.5.0beta12 does not sanitize paths in x-man-page URLs. They may have shell metacharacters for a /usr/bin/man command line.
iTerm2 before 3.4.20 allow (potentially remote) code execution because of mishandling of certain escape sequences related to upload.
iTerm2 before 3.4.20 allow (potentially remote) code execution because of mishandling of certain escape sequences related to tmux integration.
iTerm2 before 3.4.18 mishandles a DECRQSS response.
iTerm2 through 3.3.6 has potentially insufficient documentation about the presence of search history in com.googlecode.iterm2.plist, which might allow remote attackers to obtain sensitive information, as demonstrated by searching for the NoSyncSearchHistory string in .plist files within public Git repositories.
A vulnerability exists in the way that iTerm2 integrates with tmux's control mode, which may allow an attacker to execute arbitrary commands by providing malicious output to the terminal. This affects versions of iTerm2 up to and including 3.3.5. This vulnerability may allow an attacker to execute arbitrary commands on their victim's computer by providing malicious output to the terminal. It could be exploited using command-line utilities that print attacker-controlled content.
iTerm2 3.x before 3.1.1 allows remote attackers to discover passwords by reading DNS queries. A new (default) feature was added to iTerm2 version 3.0.0 (and unreleased 2.9.x versions such as 2.9.20150717) that resulted in a potential information disclosure. In an attempt to see whether the text under the cursor (or selected text) was a URL, the text would be sent as an unencrypted DNS query. This has the potential to result in passwords and other sensitive information being sent in cleartext without the user being aware.