DEV Community: Amartya Jha

CVE-2024-6387: Critical OpenSSH Vulnerability Allowing Root Access

Amartya Jha — Mon, 06 Apr 2026 17:42:49 +0000

The Qualys Threat Research Unit (TRU) has uncovered CVE-2024-6387, a serious vulnerability in OpenSSH running on glibc-based Linux systems. This unauthenticated Remote Code Execution (RCE) flaw lets attackers gain full root access in the default configuration, without any user interaction.

What makes CVE-2024-6387 especially dangerous is that it’s not a brand-new bug. Instead, it’s a regression of CVE-2006-5051, a vulnerability patched nearly two decades ago but accidentally reintroduced in OpenSSH 8.5p1 (October 2020).

Why CVE-2024-6387 Matters

OpenSSH is one of the most widely used components in Linux infrastructure. A flaw in its default configuration means millions of servers could be exposed, cloud providers, enterprise systems, and even critical infrastructure. Because attackers don’t need valid credentials or user interaction, exploitation risk is extremely high.

This makes it vital to understand which versions are affected and how to quickly detect vulnerable deployments before attackers do.

Affected OpenSSH Versions

Versions earlier than 4.4p1: OpenSSH versions earlier than 4.4p1 are vulnerable to this signal handler race condition unless they have been patched for CVE-2006-5051 and CVE-2008-4109.

Versions 4.4p1 to 8.4p1: Versions from 4.4p1 up to, but not including, 8.5p1 are not vulnerable due to a transformative patch for CVE-2006-5051, which made a previously unsafe function secure.
Versions 8.5p1 to 9.7p1: The vulnerability resurfaces in versions from 8.5p1 up to, but not including, 9.8p1 due to the accidental removal of a critical component in a function.

Detection

This script enables the scanning of multiple IP addresses, domain names, and CIDR network ranges to detect potential vulnerabilities and ensures rapid security of your infrastructure.

Save this below code as cve_2024-6387_check.py

!/usr/bin/env python3

import socket
import argparse
import ipaddress
import threading
import time
from queue import Queue
from concurrent.futures import ThreadPoolExecutor

VERSION = "0.5"
BLUE = "\033[94m"
GREEN = "\033[92m"
RED = "\033[91m"
ORANGE = "\033[33m"
ENDC = "\033[0m"

progress_lock = threading.Lock()
progress_counter = 0
total_hosts = 0

def display_banner():
banner = rf"""{BLUE}
__ ____________ _____ _______ _ __
/ / / / / |/ / / | / / _/ | / | / /
/ // / / / / /|/ / /| |/ // / | |/ |/ /
/_// // // /// |// |/|/
{ENDC}
{RED}Vulnerability Checker{ENDC}
v{VERSION} / Alex Hagenah / @xaitax / ah@primepage.de
"""
print(banner)

def get_ssh_banner(ip, port, timeout):
try:
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.settimeout(timeout)
sock.connect((ip, port))
banner = sock.recv(1024).decode('errors'='ignore').strip()
sock.close()
return banner
except Exception as e:
return None

def check_vulnerability(ip, port, timeout, result_queue):
global progress_counter
banner = get_ssh_banner(ip, port, timeout)

if not banner:
    result_queue.put((ip, 'closed', 'Port closed'))
    with progress_lock:
        progress_counter += 1
    return

if "SSH-2.0-OpenSSH" not in banner:
    result_queue.put((ip, 'unknown', f'Failed to retrieve SSH banner: {banner}'))
    with progress_lock:
        progress_counter += 1
    return

vulnerable_versions = [
    'SSH-2.0-OpenSSH_1',
    'SSH-2.0-OpenSSH_2',
    'SSH-2.0-OpenSSH_3',
    'SSH-2.0-OpenSSH_4.0',
    'SSH-2.0-OpenSSH_4.1',
    'SSH-2.0-OpenSSH_4.2',
    'SSH-2.0-OpenSSH_4.3',
    'SSH-2.0-OpenSSH_8.5',
    'SSH-2.0-OpenSSH_8.6',
    'SSH-2.0-OpenSSH_8.7',
    'SSH-2.0-OpenSSH_8.8',
    'SSH-2.0-OpenSSH_8.9',
    'SSH-2.0-OpenSSH_9.0',
    'SSH-2.0-OpenSSH_9.1',
    'SSH-2.0-OpenSSH_9.2',
    'SSH-2.0-OpenSSH_9.3',
    'SSH-2.0-OpenSSH_9.4',
    'SSH-2.0-OpenSSH_9.5',
    'SSH-2.0-OpenSSH_9.6',
    'SSH-2.0-OpenSSH_9.7',
]

excluded_versions = [
    'SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.10',
    'SSH-2.0-OpenSSH_9.3p1 Ubuntu-3ubuntu3.6',
    'SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u3',
]

if any(version in banner for version in vulnerable_versions) and not any(excluded in banner for excluded in excluded_versions):
    result_queue.put((ip, 'vulnerable', banner))
else:
    result_queue.put((ip, 'not_vulnerable', f'{banner}'))

with progress_lock:
    progress_counter += 1

def process_ip_list(ip_list_file):
try:
with open(ip_list_file, 'r') as file:
ips = [line.strip() for line in file.readlines()]
return [ip for ip in ips if ip]
except FileNotFoundError:
print(f"{RED}[-]{ENDC} Could not find file: {ip_list_file}")
return []

def main():
global total_hosts
display_banner()
parser = argparse.ArgumentParser(description="Check running versions of OpenSSH (CVE-2024-6387).")
parser.add_argument("targets", nargs='*', help="IP addresses, domain names, CIDR networks, or file paths.")
parser.add_argument("-t", "--timeout", type=float, default=1.0, help="Connection timeout in seconds (default: 1.0).")
parser.add_argument("-l", "--list", help="File containing a list of IP addresses to check.")
parser.add_argument("--port", type=int, default=22, help="Connection timeout in seconds (default: 1 second).")

args = parser.parse_args()
targets = args.targets
port = args.port
timeout = args.timeout

ips = []

if args.list:
    ips.extend(process_ip_list(args.list))

for target in targets:
    try:
        with open(target, 'r') as file:
            ips.extend(file.read().splitlines())
    except IOError:
        if '/' in target:
            try:
                network = ipaddress.ip_network(target, strict=False)
                ips.extend([str(ip) for ip in network.hosts()])
            except ValueError:
                print(f"{RED}[-]{ENDC} Invalid CIDR notation: {target}")
        else:
            ips.append(target)

result_queue = Queue()
total_hosts = len(ips)

max_workers = 100
with ThreadPoolExecutor(max_workers=max_workers) as executor:
    futures = [executor.submit(check_vulnerability, ip, port, timeout, result_queue) for ip in ips]

    while any(future.running() for future in futures):
        with progress_lock:
            print(f"\rProgress: {progress_counter}/{total_hosts} hosts scanned", end="")
        time.sleep(0.1)

print(f"\rProgress: {progress_counter}/{total_hosts} hosts scanned")

total_scanned = len(ips)
closed_ports = []
unknown = []
not_vulnerable = []
vulnerable = []

while not result_queue.empty():
    ip, status, message = result_queue.get()
    if status == 'closed':
        closed_ports += [1]
    elif status == 'unknown':
        unknown.append((ip, message))
    elif status == 'vulnerable':
        vulnerable.append((ip, message))
    else:
        not_vulnerable.append((ip, message))

print(f"\n{BLUE}[*]{ENDC} Servers not vulnerable: {len(not_vulnerable)}")
for ip, msg in not_vulnerable:
    print(f"{GREEN}[+]{ENDC} Server at {ip}: {msg}")
print(f"\n{RED}[+]{ENDC} Servers likely vulnerable: {len(vulnerable)}")
for ip, msg in vulnerable:
    print(f"{RED}[+]{ENDC} Server at {ip}: {msg}")
print(f"\n{ORANGE}[+]{ENDC} Servers with unknown SSH Version: {len(unknown)}")
for ip, msg in unknown:
    print(f"{ORANGE}[+]{ENDC} Server at {ip}: {msg}")
print(f"\n{BLUE}[*]{ENDC} Servers with port {port} closed: {len(closed_ports)}")
print(f"{BLUE}[*]{ENDC} Total scanned targets: {total_scanned}\n")

if name == "main":
main()#!/usr/bin/env python3
import socket
import argparse
import ipaddress
import threading
import time
from queue import Queue
from concurrent.futures import ThreadPoolExecutor

VERSION = "0.5"
BLUE = "\033[94m"
GREEN = "\033[92m"
RED = "\033[91m"
ORANGE = "\033[33m"
ENDC = "\033[0m"

progress_lock = threading.Lock()
progress_counter = 0
total_hosts = 0

def check_vulnerability(ip, port, timeout, result_queue):
global progress_counter
banner = get_ssh_banner(ip, port, timeout)

if not banner:
    result_queue.put((ip, 'closed', 'Port closed'))
    with progress_lock:
        progress_counter += 1
    return

if "SSH-2.0-OpenSSH" not in banner:
    result_queue.put((ip, 'unknown', f'Failed to retrieve SSH banner: {banner}'))
    with progress_lock:
        progress_counter += 1
    return

vulnerable_versions = [
    'SSH-2.0-OpenSSH_1',
    'SSH-2.0-OpenSSH_2',
    'SSH-2.0-OpenSSH_3',
    'SSH-2.0-OpenSSH_4.0',
    'SSH-2.0-OpenSSH_4.1',
    'SSH-2.0-OpenSSH_4.2',
    'SSH-2.0-OpenSSH_4.3',
    'SSH-2.0-OpenSSH_8.5',
    'SSH-2.0-OpenSSH_8.6',
    'SSH-2.0-OpenSSH_8.7',
    'SSH-2.0-OpenSSH_8.8',
    'SSH-2.0-OpenSSH_8.9',
    'SSH-2.0-OpenSSH_9.0',
    'SSH-2.0-OpenSSH_9.1',
    'SSH-2.0-OpenSSH_9.2',
    'SSH-2.0-OpenSSH_9.3',
    'SSH-2.0-OpenSSH_9.4',
    'SSH-2.0-OpenSSH_9.5',
    'SSH-2.0-OpenSSH_9.6',
    'SSH-2.0-OpenSSH_9.7',
]

excluded_versions = [
    'SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.10',
    'SSH-2.0-OpenSSH_9.3p1 Ubuntu-3ubuntu3.6',
    'SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u3',
]

if any(version in banner for version in vulnerable_versions) and not any(excluded in banner for excluded in excluded_versions):
    result_queue.put((ip, 'vulnerable', banner))
else:
    result_queue.put((ip, 'not_vulnerable', f'{banner}'))

with progress_lock:
    progress_counter += 1

args = parser.parse_args()
targets = args.targets
port = args.port
timeout = args.timeout

ips = []

if args.list:
    ips.extend(process_ip_list(args.list))

for target in targets:
    try:
        with open(target, 'r') as file:
            ips.extend(file.read().splitlines())
    except IOError:
        if '/' in target:
            try:
                network = ipaddress.ip_network(target, strict=False)
                ips.extend([str(ip) for ip in network.hosts()])
            except ValueError:
                print(f"{RED}[-]{ENDC} Invalid CIDR notation: {target}")
        else:
            ips.append(target)

result_queue = Queue()
total_hosts = len(ips)

max_workers = 100
with ThreadPoolExecutor(max_workers=max_workers) as executor:
    futures = [executor.submit(check_vulnerability, ip, port, timeout, result_queue) for ip in ips]

    while any(future.running() for future in futures):
        with progress_lock:
            print(f"\rProgress: {progress_counter}/{total_hosts} hosts scanned", end="")
        time.sleep(0.1)

print(f"\rProgress: {progress_counter}/{total_hosts} hosts scanned")

total_scanned = len(ips)
closed_ports = []
unknown = []
not_vulnerable = []
vulnerable = []

while not result_queue.empty():
    ip, status, message = result_queue.get()
    if status == 'closed':
        closed_ports += [1]
    elif status == 'unknown':
        unknown.append((ip, message))
    elif status == 'vulnerable':
        vulnerable.append((ip, message))
    else:
        not_vulnerable.append((ip, message))

print(f"\n{BLUE}[*]{ENDC} Servers not vulnerable: {len(not_vulnerable)}")
for ip, msg in not_vulnerable:
    print(f"{GREEN}[+]{ENDC} Server at {ip}: {msg}")
print(f"\n{RED}[+]{ENDC} Servers likely vulnerable: {len(vulnerable)}")
for ip, msg in vulnerable:
    print(f"{RED}[+]{ENDC} Server at {ip}: {msg}")
print(f"\n{ORANGE}[+]{ENDC} Servers with unknown SSH Version: {len(unknown)}")
for ip, msg in unknown:
    print(f"{ORANGE}[+]{ENDC} Server at {ip}: {msg}")
print(f"\n{BLUE}[*]{ENDC} Servers with port {port} closed: {len(closed_ports)}")
print(f"{BLUE}[*]{ENDC} Total scanned targets: {total_scanned}\n")

VERSION = "0.5"
BLUE = "\033[94m"
GREEN = "\033[92m"
RED = "\033[91m"
ORANGE = "\033[33m"
ENDC = "\033[0m"

progress_lock = threading.Lock()
progress_counter = 0
total_hosts = 0

def check_vulnerability(ip, port, timeout, result_queue):
global progress_counter
banner = get_ssh_banner(ip, port, timeout)

if not banner:
    result_queue.put((ip, 'closed', 'Port closed'))
    with progress_lock:
        progress_counter += 1
    return

if "SSH-2.0-OpenSSH" not in banner:
    result_queue.put((ip, 'unknown', f'Failed to retrieve SSH banner: {banner}'))
    with progress_lock:
        progress_counter += 1
    return

vulnerable_versions = [
    'SSH-2.0-OpenSSH_1',
    'SSH-2.0-OpenSSH_2',
    'SSH-2.0-OpenSSH_3',
    'SSH-2.0-OpenSSH_4.0',
    'SSH-2.0-OpenSSH_4.1',
    'SSH-2.0-OpenSSH_4.2',
    'SSH-2.0-OpenSSH_4.3',
    'SSH-2.0-OpenSSH_8.5',
    'SSH-2.0-OpenSSH_8.6',
    'SSH-2.0-OpenSSH_8.7',
    'SSH-2.0-OpenSSH_8.8',
    'SSH-2.0-OpenSSH_8.9',
    'SSH-2.0-OpenSSH_9.0',
    'SSH-2.0-OpenSSH_9.1',
    'SSH-2.0-OpenSSH_9.2',
    'SSH-2.0-OpenSSH_9.3',
    'SSH-2.0-OpenSSH_9.4',
    'SSH-2.0-OpenSSH_9.5',
    'SSH-2.0-OpenSSH_9.6',
    'SSH-2.0-OpenSSH_9.7',
]

excluded_versions = [
    'SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.10',
    'SSH-2.0-OpenSSH_9.3p1 Ubuntu-3ubuntu3.6',
    'SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u3',
]

if any(version in banner for version in vulnerable_versions) and not any(excluded in banner for excluded in excluded_versions):
    result_queue.put((ip, 'vulnerable', banner))
else:
    result_queue.put((ip, 'not_vulnerable', f'{banner}'))

with progress_lock:
    progress_counter += 1

args = parser.parse_args()
targets = args.targets
port = args.port
timeout = args.timeout

ips = []

if args.list:
    ips.extend(process_ip_list(args.list))

for target in targets:
    try:
        with open(target, 'r') as file:
            ips.extend(file.read().splitlines())
    except IOError:
        if '/' in target:
            try:
                network = ipaddress.ip_network(target, strict=False)
                ips.extend([str(ip) for ip in network.hosts()])
            except ValueError:
                print(f"{RED}[-]{ENDC} Invalid CIDR notation: {target}")
        else:
            ips.append(target)

result_queue = Queue()
total_hosts = len(ips)

max_workers = 100
with ThreadPoolExecutor(max_workers=max_workers) as executor:
    futures = [executor.submit(check_vulnerability, ip, port, timeout, result_queue) for ip in ips]

    while any(future.running() for future in futures):
        with progress_lock:
            print(f"\rProgress: {progress_counter}/{total_hosts} hosts scanned", end="")
        time.sleep(0.1)

print(f"\rProgress: {progress_counter}/{total_hosts} hosts scanned")

total_scanned = len(ips)
closed_ports = []
unknown = []
not_vulnerable = []
vulnerable = []

while not result_queue.empty():
    ip, status, message = result_queue.get()
    if status == 'closed':
        closed_ports += [1]
    elif status == 'unknown':
        unknown.append((ip, message))
    elif status == 'vulnerable':
        vulnerable.append((ip, message))
    else:
        not_vulnerable.append((ip, message))

print(f"\n{BLUE}[*]{ENDC} Servers not vulnerable: {len(not_vulnerable)}")
for ip, msg in not_vulnerable:
    print(f"{GREEN}[+]{ENDC} Server at {ip}: {msg}")
print(f"\n{RED}[+]{ENDC} Servers likely vulnerable: {len(vulnerable)}")
for ip, msg in vulnerable:
    print(f"{RED}[+]{ENDC} Server at {ip}: {msg}")
print(f"\n{ORANGE}[+]{ENDC} Servers with unknown SSH Version: {len(unknown)}")
for ip, msg in unknown:
    print(f"{ORANGE}[+]{ENDC} Server at {ip}: {msg}")
print(f"\n{BLUE}[*]{ENDC} Servers with port {port} closed: {len(closed_ports)}")
print(f"{BLUE}[*]{ENDC} Total scanned targets: {total_scanned}\n")

if name == "main":
main()### Usage
Running script for individual IP address

python cve-2024-6387_Check.py [--port PORT]python cve-2024-6387_Check.py [--port PORT]python cve-2024-6387_Check.py [--port PORT]### Examples
Single IP

python cve-2024-6387_Check.py 192.168.1.1python cve-2024-6387_Check.py 192.168.1.1python cve-2024-6387_Check.py 192.168.1.1Running script for multiple IPs

python cve-2024-6387_Check.py -l ip_list.txtpython cve-2024-6387_Check.py -l ip_list.txtpython cve-2024-6387_Check.py -l ip_list.txtRunning script for multiple IPs and domains

python cve-2024-6387_Check.py example.com 192.168.1.2python cve-2024-6387_Check.py example.com 192.168.1.2python cve-2024-6387_Check.py example.com 192.168.1.2Running script for CIDR range

python cve-2024-6387_Check.py 192.168.1.0/24python cve-2024-6387_Check.py 192.168.1.0/24python cve-2024-6387_Check.py 192.168.1.0/24Running script with custom port

python cve-2024-6387_Check.py example.com --port 2222python cve-2024-6387_Check.py example.com --port 2222python cve-2024-6387_Check.py example.com --port 2222### What all it will check

Rapid Scanning: Quickly scan multiple IP addresses, domain names, and CIDR ranges for the CVE-2024-6387 vulnerability.
Multi-threading: Uses threading for concurrent checks, significantly reducing scan times.
Banner Retrieval: Efficiently retrieves SSH banners without authentication.
Port Check: Identifies closed ports and provides a summary of non-responsive hosts.
Detailed Output: Provides clear, emoji-coded output summarizing scan results.

Scan Results

The script will provide a summary of the scanned targets:

Vulnerable: Servers running a vulnerable version of OpenSSH.
Not Vulnerable: Servers running a non-vulnerable version of OpenSSH.
Closed Ports: Total number of targets with port 22 (or specified port) closed.

Sample Output

Check out best code review tools

Credit

Credits to Alexander Hagenah, Cybersecurity Leader, for rapidly developing the detection script for the CVE-2024-6387 vulnerability. With over two decades of experience in cybersecurity, he has evolved from an ethical hacker to an international cybersecurity strategist.

https://primepage.de/

Related CVEs to Watch

This isn’t the first time a regression exposed critical systems:

CVE-2025-3066: The Google Chrome Vulnerability You Shouldn’t Ignore

Amartya Jha — Mon, 06 Apr 2026 17:41:54 +0000

What is Google Chrome CVE-2025-3066 Vulnerability?

CVE-2025-3066 is a vulnerability that exists in Google Chrome’s Site Isolation component, a feature designed to protect different websites from interfering with each other in the browser. Ironically, the very system built to keep you safe is where this bug has crept in.

This is categorized as a “Use After Free” vulnerability. Don’t worry if that sounds confusing, it’s simpler than it seems. We'll explain it in a second.

The vulnerability was reported to Google by a security researcher and was quickly acknowledged as high severity. Google responded fast by rolling out an update to patch the issue, but if you're still using an older version of Chrome, your browser might be at risk.

What is a “Use After Free” Vulnerability?

This type of bug is one of the most common and dangerous memory corruption issues in modern software. Here’s a simple explanation:

Imagine this:

You book a hotel room, check out the next day, and the hotel gives the same room to another guest. But for some reason, you still have a keycard that opens the room. You decide to walk back in and use the room, even though it’s not supposed to be yours anymore.That’s essentially a “Use After Free” bug in programming. A section of memory (the “room”) is freed (no longer needed), but the code still uses it afterwards. This can lead to unexpected behaviors—like letting someone else (an attacker) take control of that space.In browsers like Chrome, where dozens of operations are running behind the scenes, such bugs can have major consequences, especially when they impact core security systems like Site Isolation.

How Does It Work?

In the case of CVE-2025-3066, the vulnerability occurs during the browser’s handling of Site Isolation tasks. Site Isolation is a Chrome feature that creates separate memory environments (called "processes") for different websites. This is supposed to prevent malicious websites from reading sensitive information from other open tabs.

However, due to improper memory management, Chrome was freeing up memory used by one process and then unexpectedly trying to reuse it, creating the exact “Use After Free” scenario.

What attackers can do:

An attacker could design a website or piece of code that exploits this bug. Once a user visits that site, the exploit can trigger a sequence where:

Memory is freed by Chrome

The attacker hijacks that memory space
Malicious code is executed within the user’s browser context

This could result in anything from:

Crashing your browser
Stealing sensitive data
Running unauthorized scripts
Or even planting deeper malware (if chained with other vulnerabilities)

And the worst part? It could happen without any interaction from you, aside from simply opening a webpage.

Who is Affected?

This vulnerability affects users running older or unpatched versions of Google Chrome, especially those who have Site Isolation enabled (which is now standard in most installations).It spans across Windows, macOS, and Linux operating systems.

You are at risk if:

You haven’t updated Chrome recentlyYou’re using extensions from unverified sourcesYou often visit unfamiliar websitesYou have multiple tabs open with sensitive logins (banking, emails, etc.)The more tabs you keep open—and the more you multitask online—the more valuable Chrome’s Site Isolation becomes. And that’s what makes this flaw so concerning.

Real-World Impact

Let’s talk impact in simple terms:

Code execution – attackers can run malicious code directly in your Chrome browser.
Data leakage – sensitive logins, session tokens, and personal information may be exposed.
Browser instability – Chrome may crash, freeze, or slow down unexpectedly.
Full system compromise – when combined with privilege escalation flaws, attackers could gain deeper control of your device.

This isn’t just a theoretical issue. In the past, similar vulnerabilities have been actively used in zero-day attacks, meaning attackers took advantage of them before companies could release fixes.

Mitigation and Recommended Actions

Luckily, Google is on top of things. An update that fixes this vulnerability has already been released.✅ Here’s what you should do right now:

1. Update Your Chrome Browser Immediately

This issue has been fixed in Google Chrome version 123.0.6312.86 and later. To check your version:

Open Chrome → Click the three dots in the corner → Go to Help > About Google ChromeChrome will automatically check for updates and install the latest version.

2. Enable Auto-Update

Make sure Chrome’s auto-update feature is enabled so you always receive the latest security patches.

3. Restart Your Browser

The update won’t take effect until you fully close and reopen your browser.

4. Be Cautious with Website Links

Avoid clicking on unfamiliar or suspicious links, especially from emails or social media.

5. Use Minimal Extensions

Extensions can introduce risks if poorly coded or compromised. Stick to trusted sources only.

6. Keep Your OS Updated

A secure browser also relies on a secure operating system, keep both updated.

Developer Notes: What You Should Know

If you’re a developer working with web technologies or browser extensions:

Test your sites in the latest browser versions
Avoid relying on deprecated or outdated APIs
Watch out for error logs related to memory or process handling
Keep an eye on Google’s Chromium blog for detailed technical write-ups

This vulnerability is a reminder that even robust features like Site Isolation can be flawed if not handled correctly. Chrome’s codebase is vast, and small mistakes in memory management can have big consequences.

Conclusion

Security is a never-ending battle between attackers and defenders. With billions of people relying on Chrome daily, even a single vulnerability can become a serious threat in the wrong hands.

CVE-2025-3066 is a wake-up call, not just for Google, but for all of us. Whether you’re a tech-savvy developer or a casual web surfer, regular updates and security hygiene are your first line of defense.

So here’s the bottom line:

Update your Chrome browser today. It takes 30 seconds, and it could save you from a very real security nightmare.

Stay safe out there, and keep an eye on CodeAnt AI for more easy-to-read breakdowns of complex security issues.

FAQs

What is CVE-2025-3066 in Google Chrome?

Which Chrome versions are affected, and am I vulnerable?

How do I fix CVE-2025-3066 right now?

What can attackers do if CVE-2025-3066 is exploited?

Is Chrome’s Site Isolation still safe to use?

No headings found on this page #### Start Your 14-Day Free Trial AI code reviews, security, and quality trusted by modern engineering teams. No credit card required!

Get StartedGet StartedShare blog:

Ship clean & secure code faster

START 14 DAYS FREE TRIALSTART 14 DAYS FREE TRIAL CONTACT SALESCONTACT SALES Product

Resources

[Customer

](../customer-story)[Enterprise

](../solution/enterprise)[IDE

](../ide)[Pricing

](../pricing)BOOK A DEMOBOOK A DEMO LOGINLOGIN Made with Love in San Francisco

355 Bryant St. San Francisco, CA 94107, USA

Ask AI for summary of CodeAnt

ProductAI Code Reviews

Code Quality Platform

Code Security Platform

Developer 360

IDE Integration

PricingStart Free Trial

CompanyAbout

LegalDPA

Report a Vulnerability

DevelopersDocumentation

Integrations

Security Research

Vulnerability Database

System Status

CompareBenchmark

CodeAnt vs SonarQube

CodeAnt vs CodeRabbit

CodeAnt vs GitHub Copilot

')" class="framer-61xnaf" aria-hidden="true">

Why ripgrep (rg) Beats grep for Modern Code Search: 5 Deep Technical Reasons

Amartya Jha — Thu, 12 Mar 2026 09:35:20 +0000

Every developer has run grep -r "someFunction" . and watched the terminal hang while it crawled through node_modules. Then discovered ripgrep. Then never looked back.

The performance gap isn't luck. It's the result of fundamental architectural decisions.

1. Rust's Memory Safety and Parallel Execution

GNU grep is single-threaded. It processes files sequentially on one CPU core. On a 16-core machine, grep uses one.

ripgrep parallelizes search across all available cores by default. Each thread takes a chunk of files and searches independently. Rust's ownership model makes data-race-free parallel programming tractable.

Practical effect: ripgrep searches 500,000 lines across thousands of files in under a second. grep may take ten to fifteen seconds. On a large monorepo, the gap widens further.

2. Smart .gitignore Respect

By default, ripgrep reads and respects .gitignore files, .ignore files, and global gitignore configurations. It skips hidden files, directories, and binary files automatically.

rg "apiKey" in a Node.js project automatically skips node_modules/, .git/, and build output. grep has no concept of .gitignore — grep -r will search every file in node_modules.

On a typical JavaScript project, node_modules can contain more files than application source. This is the difference between a useful tool and an unusable one.

3. Unicode Handling by Default

grep was designed for ASCII. Unicode requires explicit flags and varies across platforms.

ripgrep is built for UTF-8. It validates and searches Unicode text correctly without flags. For modern codebases with international strings, comments, and documentation, this matters.

4. Guaranteed Linear-Time Regex Matching

grep uses a backtracking regex engine with a well-documented pathological failure: catastrophic backtracking. Certain patterns against certain inputs cause exponential time complexity.

ripgrep uses Rust's regex crate, built on finite automata with guaranteed O(n) time complexity. No catastrophic backtracking, ever.

The Rust regex crate also implements SIMD-accelerated literal searching — when your pattern contains a literal string, ripgrep uses vectorized CPU instructions to scan at memory bandwidth speeds.

5. Recursive Search as Default

rg pattern searches the current directory recursively, respecting .gitignore, skipping binaries, with file names and line numbers. The default behavior is what developers actually want 95% of the time.

grep requires -r for recursive search, -l for filenames only, --exclude-dir for filtering. Building the right invocation is an exercise in flag memorization.

When grep Still Makes Sense

POSIX compliance in portable shell scripts
Simple pipes where universal availability matters
Searching a single known file where performance difference is negligible
Binary data in certain pipeline contexts

For interactive development work on codebases of any meaningful size, the case for ripgrep is overwhelming.

About CodeAnt AI

CodeAnt AI builds efficient code analysis into its platform. The same principles that make ripgrep fast — parallelism, smart filtering, efficient matching — inform how CodeAnt approaches codebase-scale analysis.

EPSS Explained: Why Exploit Prediction Scoring Changes Everything for Vulnerability Prioritization

Amartya Jha — Thu, 12 Mar 2026 09:35:18 +0000

Your security scanner just flagged 847 vulnerabilities. Your team can fix 20 this sprint. Which 20?

If your answer is "the ones with the highest CVSS scores," you're using an imperfect heuristic that leaves your real attack surface exposed while you remediate vulnerabilities that will never be exploited.

The Problem with CVSS Alone

CVSS measures theoretical severity: how bad would this be if exploited? What it doesn't measure is likelihood: how probable is it that this vulnerability will actually be exploited?

Fewer than 5% of published CVEs are ever observed being exploited in the wild. A CVSS 9.8 vulnerability with no public exploit code may sit indefinitely unexploited. Meanwhile, a CVSS 6.5 vulnerability that's trivial to exploit may be actively used in attacks within days.

What EPSS Is

The Exploit Prediction Scoring System assigns each CVE a probability score between 0 and 1 representing the likelihood of exploitation within the next 30 days.

The model uses:

Exploit availability. Public proof-of-concept code in Metasploit or ExploitDB.
Threat intelligence feeds. References in threat actor communication, honeypot logs.
Social media signals. Discussions by security researchers, blog posts.
Temporal dynamics. Scores update daily with new information.
Historical patterns. Characteristics that correlate with real-world weaponization.

How EPSS Changes Prioritization

CVE-A: CVSS 9.8. No public exploit, no threat actor interest. EPSS: 0.003 (0.3%).

CVE-B: CVSS 6.5. Public exploit last week, ransomware groups targeting it. EPSS: 0.847 (84.7%).

Pure CVSS prioritization fixes CVE-A first. EPSS correctly identifies CVE-B as urgent.

The EPSS + CVSS Framework

High CVSS + High EPSS: Fix immediately
High CVSS + Low EPSS: Schedule remediation
Low CVSS + High EPSS: Prioritize above severity rating
Low CVSS + Low EPSS: Standard backlog

EPSS Limitations

A low EPSS score reflects current intelligence, not a permanent assessment. EPSS reflects population-level risk, not organizational context. And EPSS covers published CVEs only — zero-days are outside scope.

How CodeAnt Integrates EPSS

CodeAnt AI incorporates EPSS scores directly into security scanning. Rather than presenting raw CVE lists ordered by CVSS, CodeAnt combines EPSS probability with severity and your codebase context to surface vulnerabilities representing genuine, current risk.

About CodeAnt AI

CodeAnt AI integrates threat intelligence including EPSS scoring to help teams prioritize and remediate vulnerabilities that represent real risk. Stop chasing theoretical severity — start addressing actual exposure.

GPT-5.1 vs GPT-5.1-Codex: Which Model Wins for Code Review?

Amartya Jha — Thu, 12 Mar 2026 09:35:16 +0000

The model landscape for code-related AI tasks has fragmented. GPT-5.1 and GPT-5.1-Codex represent a relevant fork: one is a powerful general reasoning model, the other optimized for code. For code review pipelines, the choice matters.

GPT-5.1: General Reasoning at Scale

Business context comprehension. Code review isn't purely technical. GPT-5.1's broad training makes it capable of reasoning about compliance risk, privacy implications, and UX tradeoffs.

Natural language quality. Review comments that engineers actually read are well-written. GPT-5.1 produces fluent, precise explanations.

Cross-domain reasoning. Security vulnerabilities often sit at the intersection of code, protocols, and infrastructure. GPT-5.1 connects dots across domains.

Limitations: Not optimized for dense, syntactically precise reasoning. Can miss subtle code-specific patterns.

GPT-5.1-Codex: Optimized for Code

Bug pattern recognition. Better at identifying off-by-one errors, null dereference patterns, resource leaks, concurrency issues.

Language-specific semantics. Deeper understanding of Python's GIL, JavaScript's event loop, Rust's ownership model.

Code generation quality for fixes. Produces higher-quality, idiomatic suggested remediations.

Limitations: Less equipped for business context, cross-domain reasoning, and communicating with non-specialist readers.

Benchmark Comparison

Bug detection: Codex wins for syntactic and algorithmic bugs. GPT-5.1 wins for bugs requiring system-level understanding.

Security scanning: Codex catches common vulnerability classes reliably. GPT-5.1 adds value for architectural security issues like broken access control.

Refactoring suggestions: Codex produces more idiomatic recommendations. GPT-5.1 better accounts for broader system design.

Neither model dominates across all dimensions.

Why Architecture Matters More Than the Model

A powerful model given a retrieved fragment of context will produce worse analysis than a weaker model given complete, accurate context. The quality of code review is bounded first by context quality, and only secondarily by model reasoning capability.

RAG-based pipelines feeding chunks to GPT-5.1-Codex will miss things that a graph-based system feeding complete dependency context to GPT-4 would catch.

CodeAnt AI is model-agnostic by design. It constructs complete code graph context before invoking any language model — so analysis starts from full situational awareness.

About CodeAnt AI

CodeAnt AI delivers AI-powered code review that works across model generations. By grounding every analysis in the full code graph, CodeAnt produces accurate reviews regardless of which LLM does the reasoning.

Why RAG Fails on Legacy Codebases

Amartya Jha — Thu, 12 Mar 2026 09:35:14 +0000

If you've ever worked in a codebase that predates the current decade, you know the feeling. Functions named processData2_final_v3. Comments describing behavior abandoned three years ago. A module that does five things, none documented.

Legacy codebases are where most critical software lives. And increasingly, teams are reaching for RAG-based AI tools to help them understand and maintain this code. It's not working.

What RAG Assumes About Code

RAG works by converting code into vector embeddings and retrieving semantically relevant chunks. The assumption: similar code has similar meaning, and meaning is captured in the embedding.

That holds for modern, well-structured code. It breaks down for legacy codebases.

Implicit Dependencies Are Invisible to Embeddings

Modern code makes dependencies explicit: imports, interface definitions, type signatures. Legacy code is full of implicit dependencies. A function that only works if a global variable has been set by a different function called in a specific order. A database table that must be locked before a transaction.

None of this is in the text. None of it survives embedding.

Tribal Knowledge Doesn't Embed

Every long-lived codebase carries tribal knowledge: "Don't call that function from a background thread." "This module assumes UTC timestamps even though the parameter is called localTime."

This knowledge was never written down because it was obvious to the people who built the system. RAG cannot recover it.

Outdated Comments Poison Retrieval

Legacy code comments are a retrieval hazard. They were accurate when written. They are frequently false now. When RAG retrieves a chunk, it retrieves the misleading comment alongside the code. The AI reasons from false premises.

This is worse than no context. Wrong context actively misleads.

Scale Breaks Practical Chunking

Legacy modules are often monolithic: thousands of lines of deeply entangled logic. Splitting into chunks destroys coherence. Increasing chunk size creates other problems. There is no chunk size that works well for code written without modern modularity.

The Right Tool: Static Analysis and Code Graph Traversal

Static analysis tools follow actual execution paths, not semantic similarity. They trace how data flows through transformation pipelines. They detect that a function modifies shared state in a way that breaks a calling function fifty layers up the call stack.

Code graph analysis treats the codebase as a connected structure rather than text chunks. It surfaces implicit dependencies by following actual invocations.

About CodeAnt AI

CodeAnt AI provides AI-powered code review built on static analysis and code graph understanding — not RAG-based retrieval. For legacy codebases and modern services alike, CodeAnt delivers analysis grounded in how your code actually executes.

Why Autonomous Dev Agents Break with RAG-Based Review

Amartya Jha — Thu, 12 Mar 2026 09:35:12 +0000

Autonomous development agents are reshaping how software gets written. Tools like Devin, SWE-Agent, and OpenAI Codex can generate hundreds of lines of code, open pull requests, and resolve issues with minimal human intervention.

But there's a crack in the foundation. Most code review systems that try to keep pace with these agents rely on RAG. And RAG is fundamentally ill-suited to reviewing the code that autonomous agents produce.

Why Agents Expose RAG's Limits

Index lag is the first killer. Autonomous agents operate at machine speed. A single task might produce a dozen commits in an hour. By the time the RAG index reflects commit three, the agent has already pushed commit seven.

Context window constraints compound the problem. Agent-generated changes tend to be sprawling — modifying schemas, ORM models, API handlers, test suites, and config files. RAG retrieves fragments: the top-k chunks most similar to the query. It cannot present a coherent view of a change spanning fifteen files.

Stale embeddings pollute retrieval. When an agent refactors a module, the embedding reflects the old structure until re-indexing completes. A reviewer asking "what does this function do?" may get an answer grounded in code that no longer exists.

Agents touch cross-cutting concerns. Human developers work in bounded areas. Agents, especially on architectural tasks, make cross-cutting changes. RAG retrieval is optimized for local similarity, not tracing how changes ripple through a call graph.

The Compounding Risk

RAG's missed context clusters around exactly the changes that matter most. A security patch applied inconsistently across call sites. An interface change breaking downstream consumers the retriever didn't surface. A race condition from concurrent modifications never seen together.

What Actually Works: Graph-Based Code Analysis

Graph-based code analysis constructs a representation of the codebase mirroring its real dependency structure. When an agent submits a change, the engine traverses the actual graph: identifying callers and callees, tracing data flows, checking interface contracts.

No index lag. The graph updates incrementally.
Full change set visibility. Every modified file is part of the analysis.
Execution path awareness. The graph knows how code executes.
Deterministic coverage. If a function is in the dependency chain, it is in the analysis.

About CodeAnt AI

CodeAnt AI constructs and analyzes the actual code graph of your repository. Whether from a human developer or an autonomous agent, CodeAnt traverses the dependency structure to understand the full impact of every change.

How LLMs Are Transforming Code Review in 2026

Amartya Jha — Thu, 12 Mar 2026 09:35:10 +0000

Three years ago, LLM-powered code review was a novelty. Engineers would paste a function into a chat interface and ask if there were any bugs. It was a party trick, not a workflow.

In 2026, LLM-powered code review has matured into a serious engineering discipline with real tools, real practices, and real limitations that the best teams understand clearly.

What LLMs Brought to Code Review

The fundamental shift: the ability to reason about code semantically, not just syntactically. Traditional static analysis works by pattern matching. LLMs can reason about what code is trying to do, evaluating whether the implementation achieves it.

This unlocked:

Pattern detection across code styles. LLMs aren't fooled by reformatting or renaming. A vulnerability wrapped in a different style is still caught.

Style and consistency analysis. LLMs learn what "this codebase's style" looks like and flag deviations.

Security scanning with context. Whether code is a security risk often depends on how it's called and what data flows through it.

Change explanation. LLMs describe what a diff actually does in plain language.

Educational feedback. LLMs explain why something is a problem and what a better approach looks like.

Where LLMs Still Struggle

Deep architectural understanding. Reasoning about whether a design fits a large, evolved system is hard. The context needed often exceeds what fits in a prompt.

Business context is invisible. LLMs have no knowledge of the product roadmap, customer commitments, or team decisions.

Cross-repository impact analysis. In microservices, understanding full impact requires reasoning across service boundaries.

Hallucination under uncertainty. When LLMs lack context, they can produce confident wrong analysis. This erodes trust.

Best Practices in 2026

Use LLMs for what they're good at. Security scanning, style consistency, explaining changes — high-value, low-hallucination applications.

Integrate into the workflow. AI review in a separate tool gets ignored. Integrated into the PR experience, it gets acted on.

Tune for precision, not recall. Teams configured for high-confidence findings get signal they trust.

Combine with deterministic analysis. For known vulnerability patterns, license compliance, and test coverage — deterministic tools give exact answers.

Treat AI findings as input, not verdict. The AI review is the start of the conversation, not the end.

The State of the Ecosystem

The differentiator among platforms has shifted from "does it use an LLM?" to "how well does it understand the full context?" Tools relying on RAG-based retrieval are showing limitations. Tools building richer code representations — graphs, dependency models, architectural maps — are delivering more accurate analysis.

About CodeAnt AI

CodeAnt AI brings together LLM-powered analysis, deep code graph understanding, and automatic sequence diagram generation for every pull request. See why leading teams are making CodeAnt their standard for AI-assisted code review.

AI Self-Review vs Peer Code Review: Why Combining Both Works Best

Amartya Jha — Thu, 12 Mar 2026 09:35:08 +0000

The debate in engineering circles has been framed poorly. "Will AI replace code review?" is the wrong question. The right question is: "What should AI be doing in the code review workflow, and what should humans be doing?"

The answer: AI and human review are complementary — not competitive.

What AI Self-Review Actually Means

"AI self-review" refers to automated analysis that happens before a PR is submitted for human review. The developer writes code, the AI immediately analyzes it, and the developer sees findings before teammates ever open the PR.

Modern AI self-review can:

Detect security vulnerabilities, including subtle ones linters miss
Identify code quality issues: dead code, inefficient patterns, poor error handling
Check for consistency with existing codebase conventions
Flag potential performance issues
Identify missing test coverage
Explain what the changed code actually does in plain language

The "self" in self-review matters. When developers get this feedback before submitting, they fix the obvious issues before anyone else sees them.

What Peer Code Review Brings

Human peer review provides things AI cannot:

Architectural judgment. Does this approach fit with where the system is headed? Is the abstraction right?

Business context. Does this implementation actually solve the problem it's supposed to?

Team knowledge. Does this align with decisions the team made three months ago that didn't make it into comments?

Design feedback. Not just "does this work?" but "is this the right way to think about this problem?"

Where Each Approach Fails Alone

AI without human review misses too much. It can catch a security flaw but may not recognize the architectural decision that will produce more flaws.

Human review without AI is slow and inconsistent. Humans miss things, especially in unfamiliar domains. When reviewers spend energy on low-order checks, they have less for higher-order questions.

The Combined Workflow

A developer opens a PR. The AI runs analysis immediately. The developer fixes obvious issues. The PR reaches human reviewers already screened. Reviewers focus on architecture, design, and business logic.

The result: faster reviews, higher quality outcomes, and better use of human judgment.

What Breaks This Model

The combined model fails when AI findings are too noisy. If the AI flags dozens of false positives, reviewers learn to ignore it. It also fails when AI and human reviews aren't integrated into the same workflow.

Good AI code review tools produce the right findings in the right context, integrated with the human review workflow.

About CodeAnt AI

CodeAnt AI is designed to work alongside your team's human code review process. CodeAnt catches security vulnerabilities, quality issues, and inconsistencies before human reviewers see the PR — so your team can focus on architectural and design decisions that require human judgment.

Why Fast-Moving Teams Abandon RAG for Code Review

Amartya Jha — Thu, 12 Mar 2026 09:35:05 +0000

There's a moment that many high-velocity engineering teams recognize. You've integrated an AI code review tool. It works reasonably well in demos and on simple PRs. Then the team ships faster, the codebase gets more complex, and the AI reviews start feeling like they're describing a different codebase than the one you're actually working in.

That's the RAG index lag problem. And it's one reason why fast-moving teams are moving away from retrieval-based AI code review tools.

What High-Velocity Teams Actually Need

High-velocity teams are defined by fast iteration cycles. Multiple deployments per day. Feature branches that diverge and merge rapidly. Concurrent PRs from different teams touching overlapping parts of the system.

Real-time accuracy. The review needs to reflect the current state of the codebase, not the state when the index was last built.

Deterministic analysis. The team can't afford probabilistic answers to structural questions. "Which services does this function call?" should have an exact answer.

Branch awareness. The AI needs to understand the context of the branch being reviewed, not just the main branch.

Refactoring comprehension. When a team refactors a module, old patterns disappear and new ones appear. A retrieval system indexed on old patterns will continue to retrieve them.

The Index Lag Problem

RAG systems work by building an embedding index of the codebase. The index is built at a point in time. When code changes, the index becomes stale.

At high velocity, the index is never current. By the time it's rebuilt, hundreds of changes have been merged. The AI is reasoning about patterns that were replaced three sprints ago.

Rapid Refactoring Breaks Retrieval

RAG has no concept of "this module used to be called X and is now called Y." The old embeddings are still in the index. The new ones are absent until re-indexing. For teams that refactor frequently, the AI is most unreliable precisely when the codebase is healthiest.

Concurrent PRs and Context Collision

High-velocity teams often have multiple PRs open simultaneously touching related parts. A RAG system indexing the main branch sees neither change. The review is generated without awareness of in-flight work.

Branch Switching and Context Confusion

RAG systems indexed on main have no awareness of feature branches. Reviews of feature branch PRs are generated with main-branch context, which may be substantially different.

Why Deterministic Analysis Wins

Deterministic code analysis doesn't have an index lag problem because it analyzes the code as it is. It doesn't have a refactoring problem because it reads the current code. It doesn't have a concurrent PR problem because it can analyze the actual state of a branch.

About CodeAnt AI

CodeAnt AI is built for teams that move fast. CodeAnt's deterministic code analysis provides accurate, real-time code review for every PR — no index lag, no stale context, no probabilistic gaps.

Why RAG Fails at Microservices Code Review at Scale

Amartya Jha — Thu, 12 Mar 2026 09:16:42 +0000

Single-service RAG limitations are annoying. At scale, they become architectural blockers.

When a startup runs three microservices, the gaps in RAG-based code analysis are tolerable. Engineers know the codebase well enough to fill in what the AI misses. When an organization runs 50 microservices, 200 services, or thousands — the gaps don't just add up. They compound.

The Compounding Problem

Every microservice added to an organization's architecture adds more potential cross-service relationships. In a system of N services, the number of potential dependencies scales roughly as N². At 10 services, there are ~100 potential relationships. At 100 services, there are 10,000.

RAG systems retrieve context from an index. As services multiply, the index grows. But the retrieval mechanism — vector similarity — doesn't get smarter as the index grows. It gets noisier. More services means more semantically similar code that isn't actually related to the change under review.

The Chunk Size Trap

RAG systems embed code in chunks. The chunk size is a fundamental parameter with no good value for microservices code review.

Small chunks capture local syntax but lose function-level and module-level context. Large chunks preserve more context but hit token limits and reduce retrieval precision.

API contracts are particularly vulnerable to chunking. A protobuf definition might be split across multiple chunks. A complex OpenAPI spec almost certainly is. The contract that governs how dozens of services interact gets fragmented.

Vector Similarity Cannot Model System Architecture

The fundamental limitation isn't a tuning problem. It's a representational problem.

Vector embeddings capture what code is. They can't capture how code relates to other code at the system level.

Consider an event-driven architecture with a dozen producers and thirty consumers. The relationships that matter for code review — which consumers are affected by a schema change — are not encoded in any embedding. They exist in the topology of the system.

The Index Lag Problem

At high-velocity organizations, code changes constantly. RAG indexes are not instantaneous — they're built on a schedule, which means there's always a lag. At scale, with many teams making many changes, the index is effectively always stale.

False Confidence at Scale

The most dangerous failure mode: the system retrieves something, the LLM produces an analysis, and the output looks authoritative. But the retrieval was incomplete. Important context was fragmented or missing.

At small scale, engineers catch these gaps through familiarity. At scale, no engineer has full familiarity with 200 services. The gaps go undetected. The bugs ship.

Graph-Based Code Analysis as the Alternative

What microservices at scale actually need is a system that builds and maintains an explicit model of the architecture. A code graph represents services as nodes and dependencies as edges. Traversal is deterministic, not probabilistic. The answer to "what services consume this API?" is exact, not approximate.

About CodeAnt AI

CodeAnt AI uses deep code graph analysis to understand your entire architecture — across services, repositories, and teams. At any scale, CodeAnt provides accurate, complete context for every pull request.

Why RAG Retrieval Fails at Microservices Code Review

Amartya Jha — Wed, 11 Mar 2026 22:40:37 +0000

Retrieval-Augmented Generation has become the default architecture for AI tools that need to reason about large codebases. The pitch is compelling: instead of trying to fit an entire codebase into a context window, you embed the code into a vector database, retrieve relevant chunks at query time, and feed those chunks to an LLM.

For many use cases, RAG works well enough. For microservices code review, it fails in ways that matter.

The Microservices Context Problem

Microservices architectures are built around bounded contexts. Each service owns its domain, exposes a well-defined interface, and communicates with other services through APIs, message queues, or events. This is great for deployment independence. It's terrible for any retrieval system that has to understand the whole picture.

When a developer submits a PR that changes how Service A calls Service B, the relevant context is distributed across at minimum two repositories. The interface contract lives in one place, the implementation in another, the consumer logic in a third, and the integration tests somewhere else entirely.

RAG systems, by design, retrieve from a single embedding space at a time. Even sophisticated multi-repo RAG setups struggle because the relationships between services aren't encoded in the embeddings — only the content of individual files is.

What Embedding-Based Retrieval Actually Captures

When you embed a function or a file, the resulting vector captures semantic similarity to other functions and files. If you query for "authentication logic," you'll retrieve code that looks like authentication logic.

But cross-service dependencies aren't a matter of semantic similarity. Whether OrderService depends on InventoryService through a specific gRPC interface is a structural fact about the system, not a semantic property of either service's code.

The consequence: when an LLM is asked to review a change to OrderService, the RAG system retrieves semantically similar code — probably other order-related functions — but misses the actual dependency on InventoryService unless that dependency happens to be in the retrieved chunks.

The Fragmentation of Cross-Service Context

In a monolith, when you change a function signature, every call site is visible in the same codebase. In a microservices architecture, changing an API endpoint in one service has implications for every consumer of that API. Those consumers live in different repositories, maintained by different teams, with their own embedding indexes.

The RAG system reviewing the producer service has no visibility into the consumers. This fragmentation means that impact analysis — one of the most valuable things a code reviewer can do — is structurally broken in RAG-based tools for microservices.

Schema and Contract Dependencies

The problem is even sharper for data schema changes. If Service A publishes an event with a certain schema and Services B, C, and D all consume it, a breaking schema change is a production incident waiting to happen.

Vector similarity retrieval has no concept of "this schema is consumed by these services." That relationship exists in the actual topology of the system, not in the semantic content of any individual file.

API contracts face the same issue. OpenAPI specs, protobuf definitions, and Avro schemas define contracts between services. RAG can't systematically check these because it doesn't have a model of the contract graph.

Event-Driven Architectures Amplify the Problem

In event-driven systems, the coupling between services is even more implicit. A producer emits an event; consumers react to it. There's no direct call in the code.

RAG retrieval based on text similarity has essentially no path to discovering these relationships. The relationship exists in the system's runtime behavior and in the schema registry, not in any file that would surface through embedding-based retrieval.

What Actually Works

The limitations of RAG for microservices code review point toward what's needed: a system that builds an explicit model of the relationships between services.

Graph-based code analysis can represent service dependencies, API contracts, and event flows as a structured graph. When a change happens, the graph can be traversed to identify all downstream effects — something retrieval-based systems fundamentally cannot do.

The right tool for microservices code review isn't a smarter retrieval system. It's a system that understands the architecture.

About CodeAnt AI

CodeAnt AI is an AI-powered code review platform built for modern software architectures. Instead of relying on RAG-based retrieval, CodeAnt uses deep code graph analysis to understand cross-service dependencies, API contracts, and the full impact of code changes.