bug: [Security] IP Spoofing Rate Limit Bypass (Billing DoS)

[Vedhant26]

Description

There is a critical IP Spoofing / Rate Limit Bypass vulnerability in the application's AI Chat endpoint. This vulnerability allows an attacker to exhaust the server's AI token quota (Gemini, Groq, Mistral), causing a Billing DoS (Denial of Service).

Vulnerability Details:
The rate limiting mechanism in app/api/chat/route.ts relies on getClientIp from lib/api-utils.ts to identify the user's IP.
However, getClientIp unconditionally trusts the X-Forwarded-For HTTP header without verifying if the request came from a trusted proxy:

export function getClientIp(request: Request): string {
    const forwarded = request.headers.get("x-forwarded-for");
    if (forwarded) return forwarded.split(",")[0].trim();
    return "unknown";
}

Exploitation Scenario:

1. The AI Chat endpoint limits users to 20 requests per minute based on their IP.
2. An attacker can write a simple script that sends a POST request to /api/chat with a continuously changing, spoofed X-Forwarded-For header (e.g., X-Forwarded-For: 1.2.3.4, then 1.2.3.5).
3. Since getClientIp extracts the spoofed IP, the rate limiter treats every request as coming from a new user.
4. The attacker bypasses the 20-request limit entirely and rapidly drains the platform's API credits, costing the repository owner money.

Impact

• Severity: High / Critical (depending on financial impact)
• Attack Vector: IP Spoofing
• Consequences: API Quota Exhaustion / Billing DoS

Proposed Fix

I have updated getClientIp to prioritize the X-Real-IP header, which is set securely by load balancers and reverse proxies (like Vercel) and cannot be easily spoofed by the client. I've prepared a PR with this fix.

Could you please assign this to me, @piyushdotcomm?
Labels to apply: bug, level 3, security, advanced

[github-actions]

👋 Thanks for opening an issue, @Vedhant26!

Our maintainers will review this issue shortly 🚀

---

📘 Before Contributing

Please read the contribution guide carefully before requesting assignment:

👉 https://github.com/piyushdotcomm/Editron/blob/main/CONTRIBUTING.md

---

🏷️ NSoC'26 / GSSoC'26 Requirement

Please clearly mention whether you are contributing via:

• NSoC'26
• GSSoC'26
• or as a regular contributor

Example: I am contributing under GSSoC'26

⚠️ Assignment requests without this information may be rejected automatically.

---

⏳ GSSoC Assignment Restriction

GSSoC contributors will only be allowed to take issue assignments after:

🗓️ May 15th, 12:00 AM IST

Before that date, assignment requests from GSSoC contributors will be automatically blocked.

---

🤖 Assignment System

To request assignment, comment: /assign or assign me

The smart assignment workflow validates:

• contributor eligibility
• NSoC/GSSoC participation mention
• active issue assignment limits
• repository contribution rules

---

⚠️ Important Repository Rules

• Do not start working before assignment
• Maximum 3 active assigned issues per contributor
• Contributors are encouraged to combine related fixes into 1–2 quality PRs instead of many small PRs
• PRs without assignment may be closed
• Spam or low-quality PRs may be rejected

Happy contributing 🎉

[Vedhant26]

Hi @piyushdotcomm! I've already written a fix for this IP Spoofing Rate Limit Bypass vulnerability. Could you please assign this issue to me and explicitly mark it with the \bug, \level 3, \security, and \advanced\ labels? Thank you! I will open the PR now.

[github-actions]

⚠️ Maintainer Ping Warning

Hi @Vedhant26,

Please avoid repeatedly pinging maintainers for assignment, review, or merge requests.

Reviews and assignments are handled in queue order. Excessive pinging may lead to spam labeling and restrictions.

Recommended wait times:

• Assignment: 12–24 hours
• Review: 24–72 hours

[piyushdotcomm]

@Vedhant26 assigned to you dont forget to star the repo

[Vedhant26]

"Thanks for the assignment, @piyushdotcomm! I've starred the repository as requested.

The merge conflicts have also been fully resolved in PR #429. The transaction safety improvements are merged, and the OAuth hijacking mitigation is strictly enforced. It's fully ready for your review whenever you have the time!"

[github-actions]

⚠️ Maintainer Ping Warning

Hi @Vedhant26,

Please avoid repeatedly pinging maintainers for assignment, review, or merge requests.

Reviews and assignments are handled in queue order. Excessive pinging may lead to spam labeling and restrictions.

Recommended wait times:

• Assignment: 12–24 hours
• Review: 24–72 hours

[Vishal-Prajapati17]

I would like to work on this issue.

After reviewing the report, my understanding is that the current rate-limiting logic may be relying on client-supplied IP headers. If X-Forwarded-For is trusted without validating that it originated from a trusted proxy, an attacker could continuously spoof IP addresses and bypass the request limits, potentially exhausting AI API quotas.

My approach would be:

• Review the current getClientIp() implementation and the deployment environment.
• Verify whether X-Forwarded-For is being trusted directly.
• Use a trusted source of client IP (such as X-Real-IP provided by the reverse proxy/platform) and add safe fallback handling.
• Test the endpoint with spoofed headers to confirm the rate limiter can no longer be bypassed.
• Ensure the fix remains compatible with the existing rate-limiting system.

Before starting implementation, I'll first validate whether the vulnerability is reproducible in the current codebase and then proceed with the fix if required.

Could you please assign this issue to me if it's available?

[github-actions]

⚠️ Maintainer Ping Warning

Hi @Vishal-Prajapati17,

Please avoid repeatedly pinging maintainers for assignment, review, or merge requests.

Reviews and assignments are handled in queue order. Excessive pinging may lead to spam labeling and restrictions.

Recommended wait times:

• Assignment: 12–24 hours
• Review: 24–72 hours