CVE-2025-40620 is a critical SQL injection flaw in TCMAN GIM, with a CVSS score of 9.8. INCIBE says TCMAN fixed it in version 1280. Treat any instance reachable from untrusted networks as exposed until you have confirmed the fix, and review your logs for unexpected requests.
What's affected
- Product: TCMAN GIM version 11, a tool for managing maintenance services and the physical assets of an organisation.
- Fixed version: INCIBE says TCMAN fixed these vulnerabilities in version 1280.
- Severity: Critical, CVSS 9.8 (vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
- Weakness: CWE-89.
- Published: 2025-05-06.
The injectable input is the User parameter of the ValidateUserAndWS endpoint. The record says an unauthenticated attacker could inject an SQL statement to obtain, update and delete all information in the database.
INCIBE advisory INCIBE-2025-0218 groups six critical GIM v11 CVEs, CVE-2025-40620 to CVE-2025-40625. Five are SQL injection in different endpoints and one is an unrestricted file upload. Each CVE needs its own check, but one upgrade closes all of them.
How to check if you're exposed
The advisory does not give a command for reading the installed version, and this is a vendor-supplied product, so the useful check is administrative:
- Find the version or build number your organisation runs.
- Compare it with the fixed version in the advisory.
- If you cannot read the build number yourself, ask the vendor to confirm in writing.
You can also run your dependency manifests and container images through the free in-browser scan to see which known CVEs affect the packages you ship. It will not find a flaw inside a vendor appliance or an unmanaged install, so keep an inventory of those too.
What to do now
- Identify every copy of TCMAN GIM you run, including test and forgotten ones.
- Confirm that your GIM build is version 1280 or later. The advisory does not describe how to read the build number from the application, so ask TCMAN or check your deployment records.
- Until that is done, remove public access where you can. Put the application behind a VPN, a network allow list or a web application firewall rule, and watch the access and database logs for unusual requests to the endpoint named above.
- Record the outcome, including the date, the version you ended on and who confirmed it, so a later audit has something to read.
- Add the product to your continuous monitoring so a future CVE against it reaches you without a manual search.
Why it matters
SQL injection happens when an application builds a database query by gluing user input into the query text. The database cannot tell where the developer's command ends and the visitor's data begins, so a crafted value can change what the query does. The class is catalogued as CWE-89 (SQL injection).
The usual fix is a parameterized query, where the SQL text and the values travel separately. Input validation helps as a second layer, but it is not a substitute. Because this flaw needs no login and no click from a victim, anything that can reach the page over the network is in range.
The record's KEV flag is false, so CISA does not list it as known to be exploited, and nothing in the sources here says it is being exploited in the wild.
Try it yourself
See how the DAST web app scan step works in practice.
Click through it at your own pace, or open it full screen.
Quick check
What does the score of 9.8 mean for TCMAN GIM?
The vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H reads as network reachable, low complexity, no privileges and no user interaction. The impact ratings are confidentiality high, integrity high, availability high. Use it to rank the work, then confirm exposure for your own deployment.
Is escaping the parameter enough to fix this?
Escaping is fragile and easy to get wrong in one place out of many. Parameterized queries are the reliable fix because the value is never treated as SQL. If you maintain the code, change the query itself rather than patching the symptom.
Sources
Last reviewed: 18 October 2026.
