CWE-1007 Base Incomplete Medium likelihood

Insufficient Visual Distinction of Homoglyphs Presented to User

This vulnerability occurs when an application shows text or symbols to users without clearly distinguishing between characters that look identical or very similar (called homoglyphs). Because users…

Definition

What is CWE-1007?

This vulnerability occurs when an application shows text or symbols to users without clearly distinguishing between characters that look identical or very similar (called homoglyphs). Because users can't easily tell these characters apart, they might misinterpret information and accidentally perform unsafe actions, like clicking a malicious link.
Homoglyphs are different characters that appear identical or nearly identical on screen. For example, a lowercase 'L' and an uppercase 'i' can look the same in many fonts, and the Latin 'A' is visually identical to the Greek 'Alpha'. While software treats these as completely different characters, users can't see the difference, creating a gap between what the system understands and what the user perceives. Attackers exploit this visual ambiguity to trick users. A common method is creating deceptive phishing links or hostnames that mimic trusted sites. Similarly, an attacker might register a username like 'Admin' (with a Cyrillic 'A') that looks identical to the real 'Admin' account, making malicious activity harder to spot in system logs. This highlights a critical need for interfaces to help users visually distinguish between potentially confusing characters.
Real-world impact

Real-world CVEs caused by CWE-1007

  • web forum allows impersonation of users with homoglyphs in account names

  • Improper character restriction in URLs in web browser

  • Incomplete denylist does not include homoglyphs of "/" and "?" characters in URLs

  • web browser does not convert hyphens to punycode, allowing IDN spoofing in URLs

  • homoglyph spoofing using punycode in URLs and certificates

  • homoglyph spoofing using punycode in URLs and certificates

  • homoglyph spoofing using punycode in URLs and certificates

How attackers exploit it

Step-by-step attacker path

  1. 1

    The following looks like a simple, trusted URL that a user may frequently access.

  2. 2

    However, the URL above is comprised of Cyrillic characters that look identical to the expected ASCII characters. This results in most users not being able to distinguish between the two and assuming that the above URL is trusted and safe. The "e" is actually the "CYRILLIC SMALL LETTER IE" which is represented in HTML as the character &#x435, while the "a" is actually the "CYRILLIC SMALL LETTER A" which is represented in HTML as the character &#x430. The "p", "c", and "o" are also Cyrillic characters in this example. Viewing the source reveals a URL of "http://www.еxаmрlе.соm". An adversary can utilize this approach to perform an attack such as a phishing attack in order to drive traffic to a malicious website.

  3. 3

    The following displays an example of how creating usernames containing homoglyphs can lead to log forgery.

  4. 4

    Assume an adversary visits a legitimate, trusted domain and creates an account named "admin", except the 'a' and 'i' characters are Cyrillic characters instead of the expected ASCII. Any actions the adversary performs will be saved to the log file and look like they came from a legitimate administrator account.

  5. 5

    Upon closer inspection, the account that generated three of these log entries is "аdmіn". Only the third log entry is by the legitimate admin account. This makes it more difficult to determine which actions were performed by the adversary and which actions were executed by the legitimate "admin" account.

Vulnerable code example

Vulnerable code

The following looks like a simple, trusted URL that a user may frequently access.

Vulnerable
http://www.еxаmрlе.соm
Attacker payload

The following looks like a simple, trusted URL that a user may frequently access.

Attacker payload
http://www.еxаmрlе.соm
Secure code example

Secure pseudo

Secure pseudo
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
  const safe = validateAndEscape(input);
  return executeWithGuards(safe);
}
What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist

How to prevent CWE-1007

  • Implementation Use a browser that displays Punycode for IDNs in the URL and status bars, or which color code various scripts in URLs. Due to the prominence of homoglyph attacks, several browsers now help safeguard against this attack via the use of Punycode. For example, Mozilla Firefox and Google Chrome will display IDNs as Punycode if top-level domains do not restrict which characters can be used in domain names or if labels mix scripts for different languages.
  • Implementation Use an email client that has strict filters and prevents messages that mix character sets to end up in a user's inbox. Certain email clients such as Google's GMail prevent the use of non-Latin characters in email addresses or in links contained within emails. This helps prevent homoglyph attacks by flagging these emails and redirecting them to a user's spam folder.
Detection signals

How to detect CWE-1007

Manual Dynamic Analysis Moderate

If utilizing user accounts, attempt to submit a username that contains homoglyphs. Similarly, check to see if links containing homoglyphs can be sent via email, web browsers, or other mechanisms.

CWE-1007

Don't catalog this weakness. Prove it's reachable.

Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.

Frequently asked questions

Frequently asked questions

What is CWE-1007?

This vulnerability occurs when an application shows text or symbols to users without clearly distinguishing between characters that look identical or very similar (called homoglyphs). Because users can't easily tell these characters apart, they might misinterpret information and accidentally perform unsafe actions, like clicking a malicious link.

How serious is CWE-1007?

MITRE rates the likelihood of exploit as Medium — exploitation is realistic but typically requires specific conditions.

What languages or platforms are affected by CWE-1007?

MITRE lists the following affected platforms: Web Based.

How can I prevent CWE-1007?

Use a browser that displays Punycode for IDNs in the URL and status bars, or which color code various scripts in URLs. Due to the prominence of homoglyph attacks, several browsers now help safeguard against this attack via the use of Punycode. For example, Mozilla Firefox and Google Chrome will display IDNs as Punycode if top-level domains do not restrict which characters can be used in domain names or if labels mix scripts for different languages. Use an email client that has strict filters…

How does Plexicus detect and fix CWE-1007?

Plexicus's SAST engine matches the data-flow signature for CWE-1007 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.

Where can I learn more about CWE-1007?

MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/1007.html. You can also reference OWASP and NIST documentation for adjacent guidance.

Ready to validate what matters?

Ready to validate what matters?

Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.

Qualification

Check whether AI Swarm Pentest fits your environment.

Share the minimum context. We will review the scope and tell you the next commercial step.

Before submitting — verify you fit

Teams with fewer than 50 developers: start a 14-day Trial instead of booking a demo. Start a 14-day Trial →

0 / 280

No commitment. If you don't fit, we'll tell you.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorised target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)