Hi @michaelnebel I think I've made changes for all your requests let me know if it's ok

I'm not sure to get you question:

Maybe OData parameter like types are only relevant for classes that extend ODataController. Should that somehow be incorporated in the logic?

Can you give more details / examples ?

Maybe OData parameter like types are only relevant for classes that extend ODataController.

I don't agree with this advice.

OData can work without inheriting from ODataController by using standard ASP.NET Core Controller or ApiController classes combined with the [EnableQuery] attribute or manual ODataQueryOptions parsing.

Therefore, the filter to speed up CodeQL database matches should have all 3 possibilities:

1. Extend ODataController; or
2. Extend Controller; or
3. Extend ApiController

For the latter two, either

1. [EnableQuery] attribute; or
2. ODataQueryOptions detected

⚠️ The head of this PR and the base branch were compared for differences in the framework coverage reports. The generated reports are available in the artifacts of this workflow run. The differences will be picked up by the nightly job after the PR gets merged.

csharp

Generated file changes for csharp

• Changes to framework-coverage-csharp.rst:

-    System,"``System.*``, ``System``",48,12495,59,5
+    System,"``System.*``, ``System``",48,12500,59,5
-    Others,"``Amazon.Lambda.APIGatewayEvents``, ``Amazon.Lambda.Core``, ``Dapper``, ``ILCompiler``, ``ILLink.RoslynAnalyzer``, ``ILLink.Shared``, ``ILLink.Tasks``, ``Internal.IL``, ``Internal.Pgo``, ``Internal.TypeSystem``, ``Microsoft.ApplicationBlocks.Data``, ``Microsoft.AspNetCore.Components``, ``Microsoft.AspNetCore.Http``, ``Microsoft.AspNetCore.Mvc``, ``Microsoft.AspNetCore.WebUtilities``, ``Microsoft.CSharp``, ``Microsoft.Data.SqlClient``, ``Microsoft.Diagnostics.Tools.Pgo``, ``Microsoft.DotNet.Build.Tasks``, ``Microsoft.DotNet.PlatformAbstractions``, ``Microsoft.EntityFrameworkCore``, ``Microsoft.Extensions.Caching.Distributed``, ``Microsoft.Extensions.Caching.Memory``, ``Microsoft.Extensions.Configuration``, ``Microsoft.Extensions.DependencyInjection``, ``Microsoft.Extensions.DependencyModel``, ``Microsoft.Extensions.Diagnostics.Metrics``, ``Microsoft.Extensions.FileProviders``, ``Microsoft.Extensions.FileSystemGlobbing``, ``Microsoft.Extensions.Hosting``, ``Microsoft.Extensions.Http``, ``Microsoft.Extensions.Logging``, ``Microsoft.Extensions.Options``, ``Microsoft.Extensions.Primitives``, ``Microsoft.Interop``, ``Microsoft.JSInterop``, ``Microsoft.NET.Build.Tasks``, ``Microsoft.VisualBasic``, ``Microsoft.Win32``, ``Mono.Linker``, ``MySql.Data.MySqlClient``, ``NHibernate``, ``Newtonsoft.Json``, ``SourceGenerators``, ``Windows.Security.Cryptography.Core``",60,2406,162,4
+    Others,"``Amazon.Lambda.APIGatewayEvents``, ``Amazon.Lambda.Core``, ``Dapper``, ``ILCompiler``, ``ILLink.RoslynAnalyzer``, ``ILLink.Shared``, ``ILLink.Tasks``, ``Internal.IL``, ``Internal.Pgo``, ``Internal.TypeSystem``, ``Microsoft.ApplicationBlocks.Data``, ``Microsoft.AspNet.OData``, ``Microsoft.AspNetCore.Components``, ``Microsoft.AspNetCore.Http``, ``Microsoft.AspNetCore.Mvc``, ``Microsoft.AspNetCore.OData.Deltas``, ``Microsoft.AspNetCore.WebUtilities``, ``Microsoft.CSharp``, ``Microsoft.Data.SqlClient``, ``Microsoft.Diagnostics.Tools.Pgo``, ``Microsoft.DotNet.Build.Tasks``, ``Microsoft.DotNet.PlatformAbstractions``, ``Microsoft.EntityFrameworkCore``, ``Microsoft.Extensions.Caching.Distributed``, ``Microsoft.Extensions.Caching.Memory``, ``Microsoft.Extensions.Configuration``, ``Microsoft.Extensions.DependencyInjection``, ``Microsoft.Extensions.DependencyModel``, ``Microsoft.Extensions.Diagnostics.Metrics``, ``Microsoft.Extensions.FileProviders``, ``Microsoft.Extensions.FileSystemGlobbing``, ``Microsoft.Extensions.Hosting``, ``Microsoft.Extensions.Http``, ``Microsoft.Extensions.Logging``, ``Microsoft.Extensions.Options``, ``Microsoft.Extensions.Primitives``, ``Microsoft.Interop``, ``Microsoft.JSInterop``, ``Microsoft.NET.Build.Tasks``, ``Microsoft.VisualBasic``, ``Microsoft.Win32``, ``Mono.Linker``, ``MySql.Data.MySqlClient``, ``NHibernate``, ``Newtonsoft.Json``, ``SourceGenerators``, ``Windows.Security.Cryptography.Core``",60,2416,162,4
-    Totals,,108,14908,415,9
+    Totals,,108,14923,415,9

• Changes to framework-coverage-csharp.csv:

+ Microsoft.AspNet.OData,,,5,,,,,,,,,,,,,,,,,,,5,
+ Microsoft.AspNetCore.OData.Deltas,,,5,,,,,,,,,,,,,,,,,,,5,
- System,59,48,12495,,6,5,12,,,4,1,,31,2,,6,15,17,5,3,,6382,6113
+ System,59,48,12500,,6,5,12,,,4,1,,31,2,,6,15,17,5,3,,6387,6113

Hey @michaelnebel I've taken into account comments from Copilot and your comments let me know if its better

Also curious about the DCA, do you have a list of projects using OData ?

Hello @michaelnebel , I'm also a bit lost, I've reverted some changes based on your comments I hope it will be better

Hello @michaelnebel , I'm also a bit lost, I've reverted some changes based on your comments I hope it will be better

Excellent! Thank you!
I have opened a draft PR with some extra commits with (some minor test re-writes and a small change to the ODataParameters logic). Could you perhaps cherry-pick them from #22441. Then I think everything is good to go after we run DCA again (even though we may not hit anything with the existing tests) 😄
Maybe you know of a good open source repo, where it will be possible to see the effect of the changes in this PR?

Maybe you know of a good open source repo, where it will be possible to see the effect of the changes in this PR?

I find this discussion about dataflow vs additional taint bit abstract, so I thought I'd chime in again and drive direct business value through actionable insights CodeQL could provide.

RaythaCMS has an active vulnerability in their ODATA filtering. I just asked Google Gemini via Google Search AI Mode, "odata cve".

Gemini responded with:

Several notable OData vulnerabilities have been reported in 2026, impacting enterprise platforms, web APIs, and client libraries.
Recent 2026 OData Vulnerabilities

• CVE-2026-7312: A critical CVSS 10.0 plaintext credential exposure in Progress Sitefinity OData web services that allows remote, unauthenticated attackers to retrieve sensitive insight credentials.
• CVE-2026-45646: A denial-of-service flaw in Microsoft ASP.NET Core OData and OData Web API caused by unlimited resource allocation, letting remote attackers exhaust server resources.
• CVE-2026-66773: An information disclosure and URL redirection issue in the SAP client library where compromised services can leak authentication data.
• CVE-2026-12076: An SQL injection vulnerability in Raytha CMS via the OData filter parsing pipeline, enabling unauthenticated remote database compromise.
• CVE-2026-27679: A missing authorization vulnerability in SAP S/4HANA OData services that lets low-privilege users modify or delete child entity records. [6, 7]

If you need help securing a specific system, tell me the software name and version so I can find relevant patches or mitigation steps.
AI responses may include mistakes.

[1] https://zeropath.com/blog/cve-2026-7312-progress-sitefinity-plaintext-credential-exposure
[2] https://www.sentinelone.com/vulnerability-database/cve-2026-45646/
[3] https://www.cve.org/CVERecord?id=CVE-2026-45646
[4] https://www.sentinelone.com/vulnerability-database/cve-2026-66773/
[5] https://nvd.nist.gov/vuln/detail/CVE-2026-12076
[6] https://www.sentinelone.com/vulnerability-database/cve-2026-27677/
[7] https://www.sentinelone.com/vulnerability-database/cve-2026-27679/

I cherry-picked the fourth issue - it turns out Raytha CMS is open source and has done done a release since December 2025, so the June 2026 CVE is currently valid ☠️ . I am guessing the actual vulnerability here is in https://github.com/RaythaHQ/raytha/blob/main/src/Raytha.Infrastructure/JsonQueryEngine/Postgres/ODataFilterToPostgres.cs#L77

@jzabroski : Thank you for the information! It appears that there are no expressions in RaythaHQ/raytha of type ODataActionParameters (at least not if I do build-mode: none extraction), which means that if an alert is missing - the root cause is different than the modelling being addressed in this PR. If you believe that there is an identified true positive missing, please open an issue.

@hugo-syn : Thank you for updating the PR. I checked approximately 1k open source repositories for expressions of type ODataActionParameters and among those I found 3. The repository with the most uses is OData/AspNetCoreOData. I will try and run DCA on this repository to see the effects.

@jzabroski : Thank you for the information! It appears that there are no expressions in RaythaHQ/raytha of type ODataActionParameters (at least not if I do build-mode: none extraction), which means that if an alert is missing - the root cause is different than the modelling being addressed in this PR. If you believe that there is an identified true positive missing, please open an issue.

In this case, RaythaCMS uses ODataQueryOptionParser to essentially bypass what OData does for free if you just build an EFCore model for it. I actually don't know why they are doing this, as it feels a bit too-clever-by-half. I am still new to CodeQL, so I don't actually know how I would automatically write a rule to detect this CVE. My guess is there would be a more general taint rule that traces control flow to find the SQL injection CWE-089 (Improper Neutralization of Special Elements used in an SQL Command) this traces back to. In this particular case, RaythaCMS should probably adopt DynamicODataToSQL rather than roll their own un-parser/sql compiler. I think if there was a taint rule for SqlKata for .FromRaw(), .WhereRaw() and .SelectRaw(), and a taint rule for ODataQueryOptionsParser, it might be possible to catch such attacks.

It seems like CodeQL is generally weak at detecting SQL Injection c.f. #16353 (for example, compared to GLM-5.2, which can plainly see the problem the way a human would)

What is not clear to me is if by adding explicit OData support, e.g. for ODataQueryOptionsParser, suddenly the CWE-089 would flag via existing rules. From how I understand CodeQL, these rules do not "compose up" across the database.

@jzabroski : The quality/coverage of a query can be different from language to language. Most of the security related queries (for instance the SQL injection) are using the CodeQL data flow library to detect paths from a set of sources to a set of sinks.
Typically, it means that if a query is missing a result, it is likely due to missing source or sink modelling (e.g. that some input is not correctly identified as a remote source or that a call to a particular method/function is not identified as a sink for the particular query).
It looks like the issue for python is mentioning missing modelling of a particular framework.
All contributions for modelling sources/sinks (and summaries) will be highly appreciated!

Asked Claude Fable 5:

PROMPT

If I wanted to build a GitHub CodeQL taint rule for OData, would ODataActionParameter or ODataQueryOptionsParser add more value?

RESPONSE

Short version: ODataQueryOptions / ODataQueryOptionParser adds far more value. ODataActionParameters is mostly already covered, and what it adds is marginal.

Why ODataActionParameters is low incremental value

It's a Dictionary<string, object> bound from the request body as a normal action-method parameter on an ODataController, which derives from ControllerBase. CodeQL's C# library already treats parameters of ASP.NET Core controller actions as RemoteFlowSource, and it already has flow summaries for Dictionary indexers and TryGetValue. So parameters["Name"] flowing into a sink is very likely flagged today with no OData-specific modeling. The only thing you'd add is a small sourceModel row for safety, and maybe ODataUntypedActionParameters. That's a ten-minute Models-as-Data addition, not a rule.

Why ODataQueryOptions is where the gap is

The framework constructs ODataQueryOptions<T> from HttpRequest inside its own plumbing, so CodeQL never sees Request.Query["$filter"] flow into it. Anything the app reads off it is invisible to taint tracking today. Concretely, the untracked sources are:

• ODataQueryOptions.RawValues.Filter / OrderBy / Apply / Expand / Select / Skip / Top / Search / Format — raw strings straight off the query string
• .Filter.RawValue, .OrderBy.RawValue, etc. on the individual option objects
• ODataQueryOptionParser.ParseFilter() / ParseOrderBy() / ParseSelectAndExpand() / ParseApply() — where the raw string is turned into a FilterClause AST; you want summary rows so taint propagates from the string into the clause, and then ConstantNode.Value and SingleValuePropertyAccessNode.Property.Name become tainted reads

The real-world bugs these catch: people who bypass ApplyTo and hand RawValues.OrderBy to System.Linq.Dynamic.Core, string-concat RawValues.Filter into FromSqlRaw/ExecuteSqlRaw, use $search or $filter text in a custom ISearchBinder/IFilterBinder that builds SQL or Elasticsearch queries, or log the raw value unsanitized (log injection). None of those are reachable by CodeQL right now.

The design trap to plan for

The standard path — options.ApplyTo(queryable) → EF translates to parameterized SQL — is safe, and if you make RawValues.* a source you'll get noise on every [EnableQuery] controller unless you add a barrier. I'd model ApplyTo and the built-in binders as sanitizers (or simply not summarize flow through them), while letting taint survive through ParseFilter into the AST nodes. Property names are validated against the EDM model, so Property.Name taint is a weaker signal than ConstantNode.Value; you could split those into two rule severities.

So: submit the ODataActionParameters source rows as a footnote in the same PR, but spend the effort on ODataQueryOptions/RawValues sources plus ODataQueryOptionParser summaries and an ApplyTo barrier. That's a rule that will actually find something.

It looks like the issue for python is mentioning missing modelling of a particular framework.
All contributions for modelling sources/sinks (and summaries) will be highly appreciated

Got it. So, while GLM-5.2 could see this, perhaps the right way to approach this is to e-mail Kyle Daigle and Mario Rogriguez and suggest a parsimonious use of Microsoft AI Research resources to test/prove out MAI models for cybersecurity threat modeling.

The general sketch of the prompt would be to harden SQL Injection CWE-089 by using package analytics across major ecosystems add add taint support for major data libraries. I predict the total budget for such robustness additions would be <$50,000 based on my personal experiences doing large scale refactorings for <$2,000.

Amazing @michaelnebel thank you for all your comments, it is my first real PR, now I have a better understanding of the architecture for maybe future PR :)