CVE-2025-65021

9.1 CRITICAL

📋 TL;DR

An Insecure Direct Object Reference (IDOR) vulnerability in Rallly allows any authenticated user to finalize polls they don't own by manipulating the pollId parameter. This enables unauthorized users to convert other users' polls into events without permission, disrupting workflows and compromising data integrity. All Rallly instances running versions before 4.5.4 are affected.

💻 Affected Systems

Products:
  • Rallly
Versions: All versions prior to 4.5.4
Operating Systems: All
Default Config Vulnerable: ⚠️ Yes
Notes: All Rallly deployments with authentication enabled are vulnerable. Self-hosted instances and cloud deployments are both affected.

📦 What is this software?

⚠️ Risk & Real-World Impact

🔴

Worst Case

Malicious authenticated users could systematically finalize all polls in the system, causing widespread disruption to scheduling workflows, data corruption, and denial of service for legitimate poll owners.

🟠

Likely Case

Unauthorized users finalize specific polls they have access to view, disrupting individual scheduling events and causing confusion among participants.

🟢

If Mitigated

With proper authorization checks, only poll owners can finalize their polls, maintaining workflow integrity and data consistency.

🌐 Internet-Facing: HIGH
🏢 Internal Only: MEDIUM

🎯 Exploit Status

Public PoC: ✅ No
Weaponized: LIKELY
Unauthenticated Exploit: ✅ No
Complexity: LOW

Exploitation requires authenticated access but is trivial - simply modifying pollId parameter in API requests. No special tools or skills needed.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: 4.5.4

Vendor Advisory: https://github.com/lukevella/rallly/security/advisories/GHSA-x7w2-g548-4qg8

Restart Required: Yes

Instructions:

1. Backup your Rallly data and configuration. 2. Update to version 4.5.4 using your deployment method (Docker, npm, etc.). 3. Restart the Rallly service. 4. Verify the update was successful.

🔧 Temporary Workarounds

Temporary API Filtering

all

Implement web application firewall rules or reverse proxy filtering to block poll finalization requests that don't match expected patterns

# Example nginx location block to restrict poll finalization
location ~* /api/polls/(.*)/finalize {
    # Add custom authorization logic here
    deny all;
}

🧯 If You Can't Patch

  • Implement application-level authorization checks in middleware to verify poll ownership before allowing finalization
  • Monitor and alert on poll finalization events from non-owners using application logs

🔍 How to Verify

Check if Vulnerable:

Test if authenticated users can finalize polls they don't own by sending a POST request to /api/polls/{other_users_poll_id}/finalize with valid authentication

Check Version:

Check Rallly version in web interface footer or via API endpoint /api/version

Verify Fix Applied:

After patching, attempt the same test - requests to finalize other users' polls should return 403 Forbidden or similar authorization error

📡 Detection & Monitoring

Log Indicators:

  • POST requests to /api/polls/*/finalize from users who don't own the poll
  • Successful poll finalization events followed by user complaints about unauthorized changes

Network Indicators:

  • Unusual patterns of poll finalization requests from single users
  • Multiple poll finalizations in short timeframes

SIEM Query:

source="rallly-logs" AND (uri_path="/api/polls/*/finalize") | stats count by user_id, poll_id | where count > threshold

🔗 References

📤 Share & Export