Why ERPNext Reports Can Ignore User Permissions (and Which Version Leaks)

I am Manoj, ERP implementation lead at Mith Tech in Bengaluru. This one is worth reading carefully rather than skimming, because the headline — "reports ignore User Permissions" — is true on one major version and inverted on the next. Version-15 users can leak rows. Version-16 users get the opposite failure: reports that abort or come back empty for no visible reason. Both trace back to the same seam.

How we verified this

Everything in this post is traced from source. I read frappe/model/db_query.py, frappe/database/query.py, frappe/desk/reportview.py and frappe/desk/query_report.py on version-15, version-16 and develop HEAD as of 5 August 2026, plus the ERPNext report call sites on version-15 and develop, and cross-checked the GitHub issue and PR state through the API.

Nothing was executed against a live bench. I have no Frappe instance in this environment. The '' return value is the issue reporter's observation in #41270; I traced the control flow independently and it is consistent with what they describe, but I did not reproduce it. The console snippets below are written from the verified source and are not execution-tested — read them before you run them, and run the audit pass read-only first.

This is a permission-enforcement bug, not a CVE. There is no severity score attached to it and I am not assigning one. It widens which rows a user sees inside a report they were already allowed to open. It does not grant access to a doctype they could not otherwise reach, does not affect list views or the REST API, and does not allow writing or deleting anything.

Start here: what does your version actually do?

The short version, before the mechanism: the exploitable fail-open through the standard report path is version-15 only. On version-16 and develop, frappe.desk.reportview.build_match_conditions() no longer routes into the legacy engine. PR #35857, merged 3 February 2026 and backported to version-16 by PR #36618, points it at frappe/database/query.py::Engine instead. That engine fails closed — with no read or select and no shared documents it raises rather than returning an empty string, and its as_condition=False path applies User Permissions with no read/select gate at all.

The legacy function itself is still there and still unfixed on all three branches. On version-16 and develop it is only reachable by code that imports DatabaseQuery from frappe.model.db_query and calls it directly — your own app, a server script, a third-party app. That is the residual exposure on modern versions, and it is a much narrower target than the standard report path.

The two gates

The function is DatabaseQuery.build_match_conditions in frappe/model/db_query.py — line 1312 on version-15, line 1025 on version-16, line 1200 on develop. It is functionally identical on all three.

There are two independent gates in it, and the bug is the gap between them.

Gate A, the deny gate, fires only when all of these hold: the doctype is not a child table, the role grants neither select nor read, ignore_permissions is falsy, and has_any_user_permission_for_doctype() is False. Only inside Gate A can a PermissionError be thrown.

Gate B, the apply gate, is the elif in the else branch:

# add user permission only if role has read perm
elif role_permissions.get("read") or role_permissions.get("select"):
    user_permissions = frappe.permissions.get_user_permissions(self.user)
    self.add_user_permissions(user_permissions)

The fourth clause of Gate A was written as an escape hatch: this user has User Permissions on this doctype, so do not hard-deny them — the User Permission machinery downstream will restrict them. That assumption only holds when Gate B also fires. Gate B is guarded by read or select, which is precisely what the scenario lacks. So the escape hatch disables the deny path without enabling the restrict path. The comment on the elif is the policy statement that opens the hole.

not self.doctype_meta.istable

The full truth table, re-derived from the source:

Three of four cells are right. The fourth returns the same value as the second, and no caller can tell them apart.

Why an empty string means "let everything through"

build_match_conditions(as_condition=True) returns a raw SQL fragment, and the caller contract is string truthiness. The canonical ERPNext shape, from erpnext/accounts/report/general_ledger/general_ledger.py on version-15:

from frappe.desk.reportview import build_match_conditions

match_conditions = build_match_conditions("GL Entry")

if match_conditions:
    conditions.append(match_conditions)

There is no sentinel for "denied". An empty string is indistinguishable from "Administrator, or a user with no User Permissions, nothing to restrict". On develop the same code has been refactored to the walrus form — if match_conditions := build_match_conditions("GL Entry"): — which is the identical test.

The as_condition=False variant has the same problem with an empty list. frappe/desk/query_report.py::get_user_match_filters builds a filter map only from truthy entries, and then get_filtered_data closes the loop:

if match_filters_per_doctype:
    for row in data:
        ...
else:
    result = list(data)     # every row, unfiltered
return result

else: result = list(data) is the literal fail-open. An empty filter set means return the entire result set. That is why the leak on version-15 also covers custom script reports you wrote yourself — including ones that never call build_match_conditions at all, because the framework's own post-filter is the thing that goes no-op.

The version-15 call sites

Thirteen call sites in ERPNext version-15 use the vulnerable if match_conditions: shape. Naming them, because these are the reports where a restricted user would actually see the extra rows:

• General Ledger — accounts/report/general_ledger/general_ledger.py
• Sales Register and Purchase Register — accounts/report/sales_register/, accounts/report/purchase_register/
• Item-wise Sales Register and Item-wise Purchase Register
• Customer/Supplier Ledger Summary — accounts/report/customer_ledger_summary/
• Balance Sheet, Profit and Loss, Trial Balance — all via accounts/report/financial_statements.py
• Daily Timesheet Summary — projects/report/daily_timesheet_summary/
• Sales Person-wise Transaction Summary — selling/report/sales_person_wise_transaction_summary/
• projects/utils.py (task query util) and accounts/utils.py::build_qb_match_conditions
• stock/dashboard/item_dashboard.py and stock/dashboard/warehouse_capacity_dashboard.py — these two call the legacy DatabaseQuery directly

I verified the call sites and the code pattern. I did not run each report as a restricted user to confirm which columns leak in practice — describe the mechanism to your team, not per-report specifics.

What is not affected

This distinction matters, because it is the reason the misconfiguration survives so long unnoticed.

List views are not exposed. frappe.get_list and reportview.get() go through DatabaseQuery.execute(), which calls check_read_permission() → frappe.has_permission() before any match conditions are built. A user with no read or select on Customer gets a hard permission error opening the Customer list, regardless of User Permissions. Same for the Report Builder view of a doctype, and same for /api/resource/<doctype>, which is the same get_list path.

So the accurate framing is: the row filter that reports rely on degrades to a no-op, while the doctype-level gate that list views rely on still holds. Everything looks correctly locked down everywhere you would think to check.

The report itself is gated on a different checkbox — frappe.has_permission(report.ref_doctype, "report"). If Report is ticked and Read is not, you have built exactly the seam this bug lives in.

The v16 half of the story

Rerouting to an engine that fails closed solved the leak and created the mirror-image problem. When a report has a Link column pointing at a doctype the user cannot read, the new engine raises PermissionError: No permission to read <DocType> and the whole report dies. PR #40124, still open, is an attempt to soften that — the example in it is Stock Ledger Variance, whose voucher_type column links to DocType itself. Issue #41286, also open, reports the user-facing version on frappe 16.28.0: a script report with a Link filter to a doctype where the user only has select throws a permission message while the data still renders.

There is also a third data point worth knowing: issue #39863 was a different fail-open introduced by the same v16 migration — the new engine returned per-doctype filter dicts in a shape that flipped AND to OR across link fields. That one was fixed by PR #40135 in June 2026.

Neither engine got the four-cell matrix right on the first attempt. And frappe/tests/test_db_query.py::test_build_match_conditions still asserts the empty string as correct:

# Before any user permission is applied
self.assertEqual(build_match_conditions(as_condition=False), [])
self.assertEqual(build_match_conditions(as_condition=True), "")

That assertion is correct for the cell it covers. The problem is that the User-Permissions-present, no-read cell has no test at all. A four-cell matrix tested in two cells is how a regression like this stays invisible for years.

Audit, harden, verify

# Pass 1 — bench --site <site> console
# Which user/doctype pairs hold User Permissions while
# their roles grant neither read nor select?

import frappe
from frappe.permissions import get_role_permissions, get_user_permissions


def audit_fail_open():
    findings = []
    users = frappe.get_all("User Permission", distinct=True, pluck="user")
    for user in users:
        if user == "Administrator":
            continue
        ups = get_user_permissions(user) or {}
        for doctype in ups:
            if not frappe.db.exists("DocType", doctype):
                continue
            if frappe.get_meta(doctype).istable:
                continue
            perms = get_role_permissions(doctype, user=user)
            if perms.get("read") or perms.get("select"):
                continue
            if perms.get("has_if_owner_enabled"):
                continue  # owner-constraint branch, not this bug
            findings.append((user, doctype, len(ups[doctype])))
    return findings


for user, doctype, n in sorted(audit_fail_open()):
    print(f"FAIL-OPEN  user={user:35s} doctype={doctype:25s} user_permissions={n}")


# Pass 2 — from frappe-bench/apps, find every caller
#
#   grep -rn --include='*.py' \
#     -e 'build_match_conditions' \
#     -e 'get_match_cond' \
#     . | grep -v '/frappe/tests/'
#
# Then isolate the vulnerable shape — an "if match:" with no else:
#
#   grep -rn --include='*.py' -A3 'build_match_conditions' . \
#     | grep -E 'if (match|.*:=)' -A1
#
# Anything of the form
#     if match_conditions:
# or  if match_conditions := build_match_conditions("GL Entry"):
# with no else branch drops the filter when the function
# returns "". Route it through safe_match_conditions().

Run it on your own instance

If you build reports regularly, the broader lesson is worth internalising alongside the ERPNext dashboards and reports guide: a hand-written frappe.db.sql in a script report opts you out of the permission-checked path entirely, and then you are relying on a post-filter you did not write and probably have not read. Preferring frappe.get_list or frappe.qb.get_query(..., ignore_permissions=False) in new reports is the durable fix.

The uncomfortable part of this one is not the missing filter — it is that the more restrictive configuration is the one that leaks, and that the symptom class has been reported on the forum continuously since 2018 without a canonical answer. Find your version, run the audit, grant select where the audit says to, and wrap the match condition in any report you wrote yourself. Then keep the test, because issue 41270 is still open and nothing upstream is going to tell you when that changes.