CVE-2026-34832: Scoold Auth Bypass Vulnerability

CVE-2026-34832 Overview

CVE-2026-34832 is an Insecure Direct Object Reference (IDOR) vulnerability in Scoold, a Q&A and knowledge sharing platform for teams. Prior to version 1.66.1, the application contains an authenticated authorization flaw in the feedback deletion functionality that allows any logged-in, low-privilege user to delete another user's feedback post by submitting its ID to POST /feedback/{id}/delete. The handler enforces authentication but does not enforce object ownership or moderator/admin authorization before allowing the deletion.

Critical Impact
Any authenticated user can delete feedback posts belonging to other users, potentially leading to data loss and disruption of the platform's knowledge sharing capabilities.

Affected Products

Scoold versions prior to 1.66.1

Discovery Timeline

April 2, 2026 - CVE-2026-34832 published to NVD
April 2, 2026 - Last updated in NVD database

Technical Details for CVE-2026-34832

Vulnerability Analysis

This vulnerability is classified as CWE-639 (Authorization Bypass Through User-Controlled Key), commonly known as an Insecure Direct Object Reference (IDOR). The flaw exists in the FeedbackController.java file within Scoold's codebase. When a user sends a POST request to the /feedback/{id}/delete endpoint, the application verifies that the user is authenticated but fails to verify whether the authenticated user owns the feedback item or has appropriate privileges (moderator/admin) to delete it.

In verification testing, a second non-privileged account successfully deleted a victim account's feedback item, and the item immediately disappeared from the feedback listing/detail views. This demonstrates a classic horizontal privilege escalation scenario where users can perform actions on resources belonging to other users at the same privilege level.

Root Cause

The root cause of this vulnerability is a missing authorization check in the deleteAjax method of FeedbackController.java. The original code only verified that a user was authenticated using utils.isAuthenticated(req) before proceeding with the deletion operation. The code failed to call utils.canEdit() or similar authorization functions to verify that the authenticated user had permission to delete the specific feedback item.

Attack Vector

An attacker with a valid low-privilege account can exploit this vulnerability remotely over the network. The attack requires the attacker to:

Authenticate to the Scoold platform with any valid user account
Identify or enumerate feedback post IDs belonging to other users
Send a POST request to /feedback/{id}/delete with the target feedback ID
The feedback is deleted without any ownership verification

java

// Vulnerable code (before patch) - FeedbackController.java
@PostMapping("/{id}/delete")
public String deleteAjax(@PathVariable String id, HttpServletRequest req) {
    if (!utils.isFeedbackEnabled()) {
        return "redirect:" + HOMEPAGE;
    }
    if (utils.isAuthenticated(req)) {
        Feedback showPost = pc.read(id);
        if (showPost != null) {
            showPost.delete();  // No ownership check!
        }
    }
    return "redirect:" + FEEDBACKLINK;
}

Source: GitHub Commit Changes

The patched version adds proper authorization checking:

java

// Patched code - FeedbackController.java
@PostMapping("/{id}/delete")
public String deleteAjax(@PathVariable String id, HttpServletRequest req, Model model) {
    if (!utils.isFeedbackEnabled()) {
        return "redirect:" + HOMEPAGE;
    }
    Feedback showPost = pc.read(id);
    if (showPost == null || !utils.canEdit(showPost, utils.getAuthUser(req))) {
        model.addAttribute("post", showPost);
        return "redirect:" + req.getRequestURI();
    }
    showPost.delete();
    return "redirect:" + FEEDBACKLINK;
}

Source: GitHub Commit Changes

Detection Methods for CVE-2026-34832

Indicators of Compromise

Unexpected deletion of feedback posts across the platform
Audit logs showing deletion requests from users who did not create the original feedback items
Multiple DELETE operations originating from a single user account targeting various feedback IDs
User complaints about missing feedback submissions they created

Detection Strategies

Monitor HTTP POST requests to /feedback/{id}/delete endpoints and correlate the requesting user with the feedback item owner
Implement application-level logging that captures the requesting user ID and the resource owner ID for all delete operations
Deploy Web Application Firewall (WAF) rules to flag anomalous patterns of delete requests across multiple resource IDs from a single session
Review application logs for high-frequency deletion attempts or systematic ID enumeration patterns

Monitoring Recommendations

Enable detailed audit logging for all CRUD operations on feedback resources
Set up alerts for deletion activities where the requesting user differs from the resource creator
Implement rate limiting on delete endpoints to slow potential mass-deletion attacks
Establish baseline metrics for normal feedback deletion patterns to detect anomalies

How to Mitigate CVE-2026-34832

Immediate Actions Required

Upgrade Scoold to version 1.66.1 or later immediately
Review recent feedback deletion logs for any signs of unauthorized deletions
Consider temporarily disabling feedback deletion functionality until the patch can be applied
Notify users if there is evidence of exploitation and restore any improperly deleted content from backups

Patch Information

The vulnerability has been patched in Scoold version 1.66.1. The fix introduces proper authorization checking using the utils.canEdit() method before allowing feedback deletion. Additionally, the ScooldUtils.java file was updated to properly handle feedback posts in the canEdit() method.

For detailed patch information, see the GitHub Security Advisory GHSA-g5fv-xw88-vw44 and the GitHub Release 1.66.1.

Workarounds

If immediate patching is not possible, implement a reverse proxy rule to restrict access to the /feedback/{id}/delete endpoint to administrators only
Deploy a WAF rule to block or log all POST requests to feedback deletion endpoints pending patch deployment
Temporarily disable the feedback feature entirely if it is not critical to operations

bash

# Example nginx configuration to restrict feedback deletion to specific IPs (admins)
location ~ ^/feedback/.*/delete$ {
    allow 192.168.1.100;  # Admin IP
    allow 192.168.1.101;  # Admin IP
    deny all;
    proxy_pass http://scoold_backend;
}