Suspected SQL injection vulnerability Injection

S R asked on October 27, 2025 15:45

We received a security alert in Azure Arc related to our Kentico 12 SQL database.
The alert flagged a potential SQL injection vulnerability in the following query:

WITH AllData AS ( SELECT *, ROW_NUMBER() OVER (ORDER BY [CategoryLevel] ASC, [CategoryOrder] ASC) AS [CMS_RN] FROM CMS_Category WHERE ([CategoryUserID] IS NULL) AND ((CategoryId = 62 AnD 7248=7248 ) AND [CategorySiteID] = @CategorySiteID) ) SELECT , (SELECT COUNT() FROM AllData) AS [CMS_TOT] FROM AllData WHERE CMS_RN BETWEEN 1 AND 100 ORDER BY CMS_RN

with a message that: Injected to vulnerable statement at offset 195 '62 AnD 7248=7248 '

The alert message indicated: "Injected to vulnerable statement at offset 195: '62 AnD 7248=7248'".

This query was executed internally by the Kentico database account. However, the presence of the injected logic 'AnD 7248=7248' suggests a possible SQL injection attempt. This pattern is commonly used by attackers to test for vulnerabilities by injecting arbitrary logic into SQL statements, potentially allowing them to manipulate queries and access unauthorized data.

Do we know what CategoryID 62 is associated with? This seems to be a false positive triggered by an internal Kentico process. I’m just looking for confirmation before I respond to the security team.

Thanks.

kentico 12

Recent Answers

Juraj Ondrus answered on October 28, 2025 05:55

The CMS_Category table hold the categories. So, the ID=62 represents some of your page categories. This sounds to me like you have some category selector somewhere on your page - perhaps reading some query string parameter. And somebody tried the SQL injection pattern adding something else to the query string. In this case in your code, when reading a query string value you need to ensure its sanitation - you need to know what values are expected and trim anything else.

1 votesVote for this answer Mark as a Correct answer

S R answered on October 28, 2025 14:39

Juraj,

Thanks for the information! I was able to query the CMS_Category for CategoryID = 62. The page in question includes multiple configured repeaters, but I wasn't able to find the specific query anywhere on the page. Since the query referenced in the original question was executed internally using the Kentico database account, it's unclear whether this constitutes a true SQL injection attack. Are there any settings within the CMS administration interface that automatically sanitize query string parameters to help mitigate vulnerabilities like cross-site scripting (XSS) and SQL injection?

Thanks, SR

0 votesVote for this answer Mark as a Correct answer

Juraj Ondrus answered on October 29, 2025 05:05

The input to the query must have been done somewhere. Yes, it is a query generated dynamically but there must be some query string parameter used on your web site, which e.g. filters pages based on category - there must be some user input somewhere.

0 votesVote for this answer Mark as a Correct answer

Brenden Kehren answered on November 3, 2025 15:00

S R,

By default, Kentico sanitizes all SQL requests to ensure there is no SQL injection. That is UNLESS you tell it otherwise by using a macro or manually write code that allows SQL injection.

Secondly, regarding this statement "Since the query referenced in the original question was executed internally using the Kentico database account, it's unclear whether this constitutes a true SQL injection attack."

Kentico has 1 connection string, by default, that is used for all calls to the database. There typically is another connection string or user name and password combination unless someone codes it in. All requests are made using the main connection string. This includes dynamically created queries created in the Kentico UI by Kentico or user created objects, queries created in code, queries generated when someone uses the Kentico API to make calls, form submissions from custom created forms, etc. Any and all of the above, if structured correctly, could result in a SQL injection attack.

This is why Kentico strongly recommends using the API when making calls because it does a better job of protecting the data and overall system than someone using SQL on their own.

0 votesVote for this answer Mark as a Correct answer