CVE-2026-46645: SQLAdmin Access Control Bypass in ajax_lookup Endpoint

Technical summary

The ajax_lookup endpoint in SQLAdmin's application.py fails to enforce the is_accessible() access control check that protects all other administrative endpoints. An authenticated attacker can directly query the ajax_lookup endpoint to retrieve data from restricted models without triggering the standard authorization validation. The vulnerability stems from inconsistent enforcement of the is_accessible() method across endpoint handlers, allowing data exfiltration from models subject to developer-defined access policies.

Business impact

For organizations using SQLAdmin with access-restricted models, this vulnerability enables authenticated employees or contractors to retrieve sensitive data they are not authorized to view. The scope is limited to users with prior authentication to the application, but the bypass is silent—organizations may not detect unauthorized data access attempts. Data exposure depends on what models developers have restricted and what sensitive information they contain. This could affect compliance posture if restricted data (PII, financial records, etc.) is accessed without audit trail alerts.

Affected systems

SQLAdmin versions prior to 0.25.1 are affected. The vulnerability requires the application to have implemented access restrictions using the is_accessible() override mechanism—applications that do not use this feature to restrict model access are not at risk, though they may have different security concerns. The issue affects any SQLAlchemy-based web application that uses SQLAdmin as an administrative interface with role-based or permission-based model restrictions.

Exploitability

Exploitation requires valid user credentials and knowledge of the ajax_lookup endpoint's existence and parameters. The attack is straightforward—an authenticated user simply crafts requests to the unprotected ajax_lookup endpoint to retrieve data. No special tools, complex attack chains, or user interaction are needed. However, the vulnerability is not exploitable by unauthenticated attackers, and it only affects applications that have explicitly configured access restrictions on models. The CVSS score of 4.3 (MEDIUM) reflects low attack complexity and the requirement for prior authentication.

Remediation

Upgrade SQLAdmin to version 0.25.1 or later. This patch ensures the ajax_lookup endpoint enforces the same is_accessible() checks as other endpoints. Organizations should prioritize patching applications that use SQLAdmin to protect sensitive models. Temporary mitigations—such as network-level restrictions on the ajax_lookup endpoint or disabling the feature—are possible but not recommended as they may break legitimate functionality.

Patch guidance

Update SQLAdmin dependency to version 0.25.1 or later. This can typically be done by updating your requirements file or package manager (pip, poetry, etc.) to specify the patched version. Test the update in a staging environment to ensure admin interface functionality remains intact, particularly for any custom ajax_lookup implementations. Version 0.25.1 contains the fix and should be deployed as part of regular maintenance windows.

Detection guidance

Monitor for requests to the /admin/ajax_lookup endpoint (or similar ajax_lookup routes depending on configuration) from authenticated users accessing restricted models. Review web application logs for patterns of ajax_lookup requests targeting model endpoints that should not be accessible to certain user roles. Check audit logs to identify if users accessed sensitive data through administrative interfaces after the vulnerability window. Examine SQLAdmin version numbers in running environments to identify which applications need patching.

Why prioritize this

While the CVSS score is MEDIUM (4.3), prioritization depends on the sensitivity of data protected by is_accessible() overrides in your environment. If you use SQLAdmin with restricted models containing PII, financial data, or other sensitive information, this should be patched promptly—authenticated insiders can silently exfiltrate that data. If you don't use SQLAdmin or don't restrict model access, this poses minimal risk. Organizations with strong authentication controls and minimal trust between internal users can defer patching but should still plan updates within standard maintenance cycles.

Risk score, explained

The CVSS 3.1 score of 4.3 reflects: Network attack vector (no physical or local access required), Low attack complexity (no special conditions), Requirement for prior authentication (PR:L), and Low impact scope (confidentiality only—no integrity or availability impact). The score appropriately captures that this is a low-privilege information disclosure, but organization-specific risk depends heavily on what data is actually restricted and who has authorized access to the SQLAdmin interface.

Frequently asked questions