CVE-2021-41765

What it actually does

CVE-2021-41765 is an unauthenticated SQL injection vulnerability in ResourceSpace 9.5 and 9.6 before revision 18274. The vulnerable endpoint, pages/edit_fields/9_ajax/add_keyword.php, accepts attacker-controlled input in the k parameter and incorporates it into SQL queries without sufficient sanitization. A remote attacker can use this to execute arbitrary SQL against the ResourceSpace database, read or modify application data, extract user session cookies, and potentially hijack an administrator session. With an administrative session, the attacker may be able to use ResourceSpace administrative functionality to achieve arbitrary code execution on the underlying server.

Why it matters to the business

Successful exploitation can result in full compromise of a ResourceSpace deployment, including disclosure of stored digital assets, metadata, user records, credentials or session data, and administrative access. Because exploitation is remote, unauthenticated, low complexity, and public exploit code is available, exposed systems are at high risk even though the issue is not currently listed in CISA KEV. Organizations using ResourceSpace for media, brand, document, or asset management may face data theft, tampering with published assets, service disruption, regulatory exposure, and attacker pivoting from the application server into adjacent systems.

How an attack unfolds

An attacker first identifies an internet-facing or otherwise reachable ResourceSpace instance running an affected 9.5 or 9.6 build before revision 18274. They send crafted HTTP requests to pages/edit_fields/9_ajax/add_keyword.php with malicious SQL syntax in the k parameter. Because the parameter is not safely handled, the injected SQL executes in the context of the ResourceSpace database user. The attacker can enumerate database structure, dump sensitive tables, and retrieve active user session cookies. If an administrator session cookie is obtained, the attacker can replay it in a browser or script to impersonate the administrator. From there, they can modify application configuration, access protected resources, create or alter users, and potentially abuse administrative features to execute code on the server.

How to fix it

Upgrade ResourceSpace to revision 18274 or later, or to a currently supported ResourceSpace release that includes the fix. If an immediate upgrade is not possible, restrict access to ResourceSpace to trusted networks or authenticated reverse-proxy users, block direct access to /pages/edit_fields/9_ajax/add_keyword.php where operationally safe, and deploy WAF rules that detect SQL injection patterns in the k parameter. Because the vulnerability can expose session cookies, invalidate all active ResourceSpace sessions after patching and force users, especially administrators, to reauthenticate. Review database user privileges and ensure the ResourceSpace database account has only the minimum permissions required by the application.

How to confirm the fix worked

Confirm the deployed ResourceSpace version or revision is 18274 or later, or that the installed release notes identify the SQL injection fix. Test that unauthenticated requests to /pages/edit_fields/9_ajax/add_keyword.php do not process attacker-controlled SQL in the k parameter and do not disclose SQL errors, timing differences, or unexpected results. Verify any compensating controls such as WAF, reverse proxy ACLs, or endpoint blocks are applied before traffic reaches the application. After remediation, confirm all active sessions have been invalidated and administrative accounts have been reviewed for unauthorized changes.

Typical attack path

1. Discover a reachable ResourceSpace instance and fingerprint the version or vulnerable endpoint behavior.
2. Send test requests to /pages/edit_fields/9_ajax/add_keyword.php with SQL metacharacters in the k parameter to confirm injection.
3. Use boolean-based, error-based, time-based, or UNION-based SQL injection techniques to enumerate the database.
4. Extract sensitive application data, including user records and active session cookies.
5. Replay a stolen administrator session cookie to gain authenticated administrative access.
6. Use administrative capabilities to access protected assets, alter application data, create persistence, or attempt server-side code execution.
7. Cover tracks by deleting or altering application records, logs, or temporary artifacts where possible.

How to detect it

Investigate web server, reverse proxy, WAF, application, database, and authentication logs for signs of exploitation. Key evidence includes unauthenticated requests to /pages/edit_fields/9_ajax/add_keyword.php with a k parameter containing SQL metacharacters, UNION SELECT payloads, boolean conditions, SQL comments, time-delay functions, or database enumeration attempts. Look for abnormal HTTP 500 responses, unusually long response times, repeated requests with changing k payloads, and large responses from the vulnerable endpoint. In database logs, look for unexpected SELECT statements against users, sessions, configuration, or schema metadata tables originating from the ResourceSpace application account. For post-exploitation, look for administrator sessions from unusual IP addresses or user agents, reuse of session cookies without normal login events, unexpected administrative actions, newly created users, changed permissions, modified configuration, suspicious uploads, and web server child processes spawning shells or command interpreters. Because exploitation may lead to code execution after session hijacking, also review host telemetry for unexpected processes launched by the web server or PHP runtime and recently modified files under the ResourceSpace web directory.

• /pages/edit_fields/9_ajax/add_keyword.php
• add_keyword.php?k=
• k=%27
• k='
• k=%22
• k="
• UNION SELECT
• UNION ALL SELECT
• information_schema
• SLEEP(
• BENCHMARK(
• WAITFOR DELAY
• OR 1=1
• OR%201=1
• AND 1=1
• AND%201=1
• --
• %2D%2D
• #
• %23
• /*
• %2F%2A
• */
• %2A%2F
• pages/edit_fields/9_ajax/add_keyword.php?k=

What your security team should do

• Prioritize patching or upgrading all ResourceSpace 9.5 and 9.6 deployments before revision 18274, especially internet-facing instances.
• Treat exposed vulnerable instances as potentially compromised because exploit code is available and exploitation is unauthenticated.
• Rotate or invalidate ResourceSpace session cookies after remediation; force administrator password resets if suspicious access is found.
• Review web server access logs for requests to /pages/edit_fields/9_ajax/add_keyword.php containing SQL injection syntax in the k parameter.
• Review ResourceSpace administrator activity for unexpected logins, new users, configuration changes, file uploads, plugin changes, or privilege changes.
• Inspect the ResourceSpace database for unauthorized modifications, newly created administrative accounts, altered configuration values, or suspicious session records.
• Restrict ResourceSpace administrative interfaces and sensitive AJAX endpoints to trusted networks where feasible.
• Deploy SIEM and WAF detections for SQL injection attempts targeting the vulnerable endpoint.
• Ensure backups are available and integrity-checked in case database tampering or server compromise is discovered.