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:

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

// 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:

// 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

# 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;
}