chore: security-only backport of critical CVE fixes to v1.29.x - #8038
Conversation
…soft#7883) Signed-off-by: Vincent Biret <vibiret@microsoft.com> Co-authored-by: Vincent Biret <vibiret@microsoft.com>
… generation (backport of microsoft#7892 / GHSA-4jwf-m4wg-8p66) Hand-ported against the pre-3.x extension shape (JsonObject/plain string) since upstream's fix depends on the typed ExtensionResponseSemanticsStaticTemplate model and an unrelated LoggerMessage refactor that don't exist on this line.
…qc-g5wc) Same-major patch bump, no Microsoft.AspNetCore.OpenApi conflict. Bisected an apparent DivergentResponseSchemaTests failure at this version to a pre-existing race on DivergentResponseSchema's shared static validStatusCodes HashSet under xUnit's parallel test execution, unrelated to this bump.
|
@microsoft-github-policy-service agree |
|
Converting to draft. Marking this because the diff here is against This PR is meant as a concrete, working reference (branch, commits, test results) for the question asked on #7999, not something to merge into |
|
Hi Eelco Los (@EelcoLos) Can you please target the branch I just created What would be interesting to do is compare the azure devops pipeline, to ensure releasing goes smoothly. |
|
Retargeted to Happy to help compare against the Azure DevOps release pipeline if useful, just point me at what to look at. |
|
https://github.com/microsoft/kiota/tree/main/.azure-pipelines is what we want to compare here |
|
Compared
Smaller/likely-fine items that are still worth knowing about:
So: as-is, running |
Pulls in main's current ci-build.yml (private feed routing, release idempotency guards) but corrects the three references that assume a newer source layout than what security/1-29-x actually has: - kiota.slnx -> kiota.sln (this branch predates the .sln to .slnx move) - publish TFM net10.0 -> net9.0 (kiota.csproj here targets net8.0/net9.0 only) - vscode/packages/npm-package/lib/runtime.json -> npm-package/runtime.json (the lib/ subfolder doesn't exist on this branch) No other changes.
|
Pushed a commit that adapts the release pipeline for this branch: pulled in
No other changes. |
|
Thanks! Now we probably need a changelog entry under changed unreleased, and then to run this script for patch https://github.com/microsoft/kiota/blob/main/scripts/bump-version.ps1 |
|
One more thing worth surfacing before this goes further: querying the advisory database for
I checked each against the actual I also test-applied each upstream fix commit against Not proposing to add all of these to this PR unprompted, wanted to flag it before this goes further since it changes what "security backport of |
|
Thank you for the additional information. I think there's only value in releasing a security patch if all the known security issues are addressed, addressing only a subset would lead to a bizarre security posture. Also I want to outline this as the goal here (why are we patching an older version)
That has the potential to unblock quite a few consumers from ASP.NET and other horizons. Let's start by porting the trivial patches onto this branch, and pause before the more complex ones, so I get time to do an initial review pass. If you can keep a clean/explicit commit history for those patches (i.e. one commit per security fix), that'd help as well in the review process. |
|
Additionally the CI is also reporting this
|
, GHSA-mr8r-92fq-pj8p, GHSA-q834-8qmm-v933) OpenTelemetry.Exporter.OpenTelemetryProtocol 1.13.1 has three known moderate-severity advisories (local blob injection via disk-retry temp path, unbounded grpc-status-details-bin parsing, unbounded OTLP HTTP response body reads). 1.15.3 is the first version patching all three. Bumps OpenTelemetry and OpenTelemetry.Extensions.Hosting to the same 1.15.3 to keep the OpenTelemetry core packages version-aligned, same pattern as the existing Microsoft.OpenApi same-major bump on this branch. Instrumentation.Http/Runtime are versioned independently upstream and unaffected by these advisories, left as-is.
Unresolved conflict markers from an earlier cherry-pick were accidentally committed. No content change beyond removing the markers and one stray blank line.
…microsoft#7603 / GHSA-2hx3-vp6r-mg3f / CVE-2026-41134) Attacker-controlled OpenAPI description content (defaults, enum values, wire names, discriminator mappings, doc comments, deprecation info) emitted as string literals into generated client code could break out of the literal and inject arbitrary code in the generated client's language, across every writer (C#, Dart, Go, HTTP, Java, PHP, Python, Ruby, TypeScript). Adds/uses per-language literal sanitizers at all emission sites. Hand-resolved conflicts against upstream's fix (Go/Java/Python getter bodies, TypeScript composed-type deserializer) were pure indentation drift and one unrelated call to SortTypesByInheritance (a feature not present on this branch); kept this branch's existing formatting/logic and applied only the sanitizer calls. Dropped one unrelated test (GetFactoryMethodName_ReturnsCamelCase_WhenTypeIsAliasedButMethodIsNot) that depends on aliased-type factory-method resolution not present on this branch.
… newlines (backport of microsoft#7735 / GHSA-7f3j-j7jj-r3vr / CVE-2026-59862) PythonConventionService.RemoveInvalidDescriptionCharacters did not strip newline characters. A malicious OpenAPI spec could inject arbitrary Python code via x-ms-enum description fields by embedding newlines that break out of inline comments (# ...) or docstrings. Dropped an unrelated dependency bump (StreamJsonRpc/Nerdbank.MessagePack/ System.CommandLine) that rode along in the upstream commit's "Secondary" changes, out of scope for this branch. Also dropped .github/instructions/writer-literal-security.instructions.md since it modifies a Copilot review-instructions file this branch doesn't have (added by an unrelated, un-backported commit, microsoft#7621).
…(backport of microsoft#7746 / GHSA-xg2h-5xr2-29jw / CVE-2026-59861) Prevent Ruby code injection in generated clients by escaping # in schema-derived values emitted into Ruby double-quoted literals. Dropped upstream's enum/datetime/date/time/guid-specific default-value formatting for backing-store/additional-data properties, an unrelated feature this branch doesn't have; kept the existing plain default-value assignment shape and applied only the Ruby sanitizer swap.
…ection (backport of microsoft#7831 / GHSA-3hrf-2gc2-mx32 / CVE-2026-59860) Newlines in an OpenAPI externalDocs.description (or other doc-comment sources) could break out of the C# /// doc comment and inject arbitrary code. Strips \r, \n, NEL, LS, PS from doc-comment text and replaces tabs with spaces before emission.
…njection (backport of microsoft#7863 / GHSA-jqwh-526h-c92j / CVE-2026-59859) PHP interpolates $var, ${...} and {$...} inside double-quoted strings. The shared SanitizeDoubleQuote helper does not escape $, so attacker-controlled OpenAPI input (descriptions, enum values, content types, discriminator/query names) emitted into PHP double-quoted literals could inject and execute arbitrary PHP/OS commands when the generated client runs. Adds SanitizePhpDoubleQuoteLiteral on PhpConventionService, mirroring the existing SanitizeDartDoubleQuoteLiteral, used at all PHP double-quote emission sites.
…ection (backport of microsoft#7884 / GHSA-4vv7-jj25-4gh6 / CVE-2026-59866) ClientClassName and ClientNamespaceName loaded from the x-ms-kiota-info OpenAPI extension (or settings) were used unsanitized in generated code and file paths, allowing an attacker-controlled OpenAPI description to inject arbitrary paths or code via those values. Test-file TestContext.Current.CancellationToken usages (xunit v3 API, unavailable on this branch's xunit 2.9.3) replaced with this branch's existing convention (new CancellationToken() / omitted).
…icrosoft#7885 / GHSA-4rj6-vrwv-wr8m / CVE-2026-59863) A workspace configuration file (kiota-config.json) committed to a repo could set a client or plugin's outputPath to an absolute path or a path escaping the workspace directory. Running kiota against that workspace would then write generated files outside the intended project tree. Validates every client/plugin outputPath against the workspace root when loading the workspace configuration, rejecting rooted or escaping paths.
|
Pushed the 7 trivial CVE fixes, one commit each as requested:
Also included Each commit builds clean and the full test suite passes locally (net8.0/net9.0, 1949/1952 relevant tests, the rest are the pre-existing flaky/network-dependent tests already noted in the PR description). Conflicts against upstream's fixes were mostly indentation drift or unrelated features this branch doesn't have (noted per-commit in each message); details on request. Pausing here before the SSRF/allow-list fix (#7888) as discussed, that's the one needing the CLI hand-port due to the System.CommandLine API change. On the changelog/version-bump ask: changelog entries are in under Unreleased > Changed (one per commit above). Holding off on |
|
Thanks for approving the run, that gave real signal. CI is red, but for reasons unrelated to the 7 commits: both failures are pre-existing on
The good news: no NU1902 errors anywhere in this run, so the OpenTelemetry bump fixed the restore failure cleanly. Both remaining issues are tooling/vintage-drift on the branch baseline, not regressions from any of the 7 security commits. Happy to fix either or both (re-format the whole tree to satisfy the current formatter, and/or work around or fix the CS9336 sites) if that's useful, just didn't want to bundle unrelated formatting churn into the security commits without checking first. |
The github/rest-api-description spec's /repos/{owner}/{repo}/contents/{path}
GET response is a union type that generates a "WithPath" model class
main's generator doesn't correctly emit (missing symbol in java,
missing file in dart, missing deserializer registration in typescript).
This is an open, unfixed kiota generator bug (main doesn't generate
correct code for it either) that main works around by suppressing
dart/typescript entirely for this spec (microsoft#7821, microsoft#7862) and excluding
just that one endpoint for java (microsoft#7829), rather than a real fix to
backport.
Added the matching per-language Suppressions/ExcludePatterns entries
to it/config.json, and backported the "Language" field filtering for
ExcludePatterns from main's 0361427 (microsoft#7774) to
get-additional-arguments.ps1 -- our version applied every
ExcludePattern to every language regardless of a Language field,
so the java-only exclude would otherwise have leaked to every
language's generation command.
Verified locally: get-additional-arguments.ps1 emits the contents/path
exclude only for java, not csharp; get-is-suppressed.ps1 suppresses
dart/typescript but not java/csharp/python for this description.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Python modules are named after the snake cased type name, so the inline schema class CodeScanningVariantAnalysis_status and the component schema class CodeScanningVariantAnalysisStatus both resolve to the same file, code_scanning_variant_analysis_status.py. One silently overwrote the other and the losing type's importers kept referencing a symbol that no longer existed, which is the mypy "has no attribute ... [attr-defined]" failure on the python integration test. Which of the two wins is nondeterministic, which is why CI reported the error in both directions (CodeScanningVariantAnalysis_status missing in one module, RepositoryRulesetConditions missing in the other). Adds a DisambiguateSnakeCasedNames pass to PythonRefiner, run right after CorrectCommonNames so it lands before imports are materialized. Sibling classes/enums are grouped by snake cased name and later collisions get a trailing underscore, ordered with StringComparer.Ordinal for determinism. Renaming the type is sufficient because CodeType.Name is computed from TypeDefinition.Name, so the file name, import path, import symbol and every type reference follow automatically; no writer changes. No upstream fix to backport: main has the same latent bug, its PythonRefiner and PythonPathSegmenter differ from this branch only by the unrelated ShortenOversizedNamespaceSegments work. Verified against the github/rest-api-description description used by the integration test. An AST scan resolving every relative import against the symbols actually present in the target module goes from 3 broken pairs to 0 of 13302. Both previously lost types are emitted again. The added test fails without the fix (Model_status vs Model_status_). Ruby and Dart segment file names the same way and so share this latent bug; left alone here to keep the change scoped to the reported failure.
A discriminator mapping can point at a composed (oneOf/anyOf) schema whose own discriminator maps back to an ancestor, so GetDiscriminatorMappings calls GetCodeTypeForMapping calls CreateModelDeclarations calls CreateComposedModelDeclaration calls GetDiscriminatorMappings with nothing to break the loop. There is no cycle detection anywhere on that path. Tracks the component schemas currently being resolved as discriminator targets, pushed before recursing and popped in a finally, so only genuine ancestor cycles are cut while the same component referenced from sibling branches still resolves. Returning null is the already established "skip this mapping" path, GetDiscriminatorMappings filters nulls out. Prerequisite for moving the Microsoft.OpenApi pin to 2.12.0: the schema shapes 2.12.0 produces close this loop and overflow the stack, aborting the whole test run. Bisected to confirm, 2.7.6, 2.10.0 and 2.11.0 are all fine and 2.12.0 is where it starts. main's ThreadLocal modelCreationDepth guard does not cover this, it wraps CreatePropertiesForModelClass and this cycle never passes through that method. Behaviour preserving on the current pin: generating the C# client for github/rest-api-description before and after gives byte identical output across all 3704 files including the log, even though the guard trips 108 times on that description. Logged at debug rather than warning for that reason, tripping here is normal rather than anomalous.
|
Both items from my last two comments turned out to be fixable. Pushed 1. Python mypy failure. Not a naming divergence as I first thought. 2. Stack overflow on 2.12.0. It is a kiota bug, not an OpenAPI.NET one: 3. Still blocking the bump, and it needs your call Vincent Biret (@baywet) . 2.12.0's V3 reader folds Relevant to you as maintainer of both repos: that fold shipped in 2.12.0 and 3.10.0 together, Pin is still 2.7.6. Tell me which way you want the Bisect table and evidenceEach row is a clean pin, restore, build and full
2.10.0 and 2.11.0 both also clear the Python fix: verified with an AST scan resolving every relative import against the symbols actually present in the target module, the same class of check as mypy's Cycle guard: The |
|
Eelco Los (@EelcoLos) Thank you for the additional information. So if I understand things correctly, both 3.10 and 2.12 reveal a new bug that we don't have a fix for at all in any branch? If my understanding is correct, it'd be interesting to start another pull request to main to address the upgrade + bugfix, and then backport that here as a way to unblock this release. What do you think? |
AllowedExternalOriginsLoadMatchingReferences failed on 2.7.6 with "Circular reference detected while resolving schema" thrown from OpenApiWorkspace.ResolveSubSchema while RegisterComponents resolved the root document's component-level external $ref. The deny path of the CVE-2026-59867 allow list was fine, but the allow path could not actually load a permitted external reference on the version 1.29.0 shipped. 2.11.0 fixes that resolution bug and is the last 2.x before the breaking changes: 2.12.0 folds anyOf: [string, integer] into a single flags-enum Type and obsoletes IOpenApiSchema.Example, which is the upgrade work that belongs on main rather than on a security branch. Full suite on 2.11.0: 1967 passed, 0 failed, 2 skipped (was 1 failure on 2.7.6). The anyOf tests pass unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VUifZksSV3pi2zWxvs29ka
Main excludes /repos/{owner}/{repo}/contents/{path}#GET for both java
and typescript; the previous backport only carried the java entry, so
typescript idempotency against the github description still crashed
generation with "Function deserializeIntoWithPath not found in
namespace ApiSdk.models". The integration suppression did not cover it
because idempotency generates the client before any comparison.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUifZksSV3pi2zWxvs29ka
The github/rest-api-description spec is tracked from its main branch,
and the /repos/{owner}/{repo} path parameter is now owner rather than
org, so the generated ReposRequestBuilder exposes byOwnerId. Matches
the same change on kiota main.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUifZksSV3pi2zWxvs29ka
|
Your understanding is right about the anyOf fold: it lands in 2.12.0 and 3.10.0 at the same time, main is still on 3.9.0, so no branch has a fix and main will hit the same wall on its next bump. Good news though, this release does not have to wait for that. I found we never actually needed 2.12: 2.11.0 is enough, and it is the last version before the fold. CI ran overnight and surfaced a real bug I had missed. That is not our code, it is OpenAPI.NET 2.7.6 failing to resolve a component level external 2.11.0 fixes that resolution bug, and it predates both breaking changes in 2.12.0 (the anyOf fold, and I also fixed the two integration failures, both pre-existing and unrelated to the security changes:
Pushed as three separate commits. |
|
While I can't share the specifics just yet, we'll need to be on version 2.12.0 or above to address all the security issues. There's has been conflicting security priorities, and issues with coordination on OpenAPI.net which lead to delays in publishing patches and other information, but I'm working to get all of that resolved by today, or tomorrow at the latest. |
|
Follow up on my previous comment, and a correction to it. I opened the main PR you asked for: #8050. While preparing it I checked the anyOf fold against the 3.x line properly instead of assuming it behaved like 2.12, and it does not affect 3.10.0. I had that part wrong.
That makes the whole thing much smaller than either of us thought:
So there is nothing here that needs a fix invented in one branch and carried to the other. Sorry for pointing you at a decision that turned out not to exist. |
|
Thank you for the additional information. So we should be safe to upgrade this branch to 2.12 based on your latest analysis? let's do so then please. |
I'm looking into it as we speak |
2.12.0 is the floor for the remaining security fixes, so 2.11.0 is not an option after all. Two things change on 2.12.0. IOpenApiSchema.Example becomes obsolete in favour of Examples, so the schema copy in PluginsGenerationService copies Examples now. The reader also folds a union of primitive types, anyOf: [string, integer], into a single Type carrying both flags and clears AnyOf. SelectFirstAnyOneOfVisitor therefore never sees a union, and the generated plugin description kept "Integer | String" where it used to narrow to "String". NarrowMultipleTypes restores a single type. Worth flagging: JsonSchemaType is a flags enum, so the order the types were authored in is gone by the time we see it, and "take the first entry" cannot be honoured literally any more. The rule is String when present, since every JSON scalar round trips through it, otherwise the lowest flag so the result stays deterministic. For anyOf: [string, integer] that reproduces the previous output exactly. Full suite on 2.12.0: 1967 passed, 0 failed, 2 skipped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VUifZksSV3pi2zWxvs29ka
|
Done, pushed. One correction before you read too much comfort into my last comment though: 2.12 is not free for this branch. My "it does not affect 3.10" finding was about main, and I should have been clearer that the reverse is what matters here. The fold does bite us on 2.12, so I fixed it rather than dodged it. Two things change on 2.12.0.
The reader folds a primitive union. I probed it directly: So I added The bit that is genuinely your call: Full suite on 2.12.0: 1967 passed, 0 failed, 2 skipped, Also added the changelog entry CI wanted on #8050, thanks for the quick approve there. |
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VUifZksSV3pi2zWxvs29ka
The changelog described the fixes but never named them, so nobody reading it could line an entry up with an advisory. Each security entry now carries its GHSA link and CVE. Two fixes on this branch had no entry at all: - the static_template.file path escape rejection (microsoft#7892 / GHSA-4jwf-m4wg-8p66) - the OpenTelemetry 1.13.1 to 1.15.3 bump (GHSA-4625-4j76-fww9, GHSA-mr8r-92fq-pj8p, GHSA-q834-8qmm-v933) Also folded GHSA-v5pm-xwqc-g5wc into the Microsoft.OpenApi entry, since that bump started as a fix for it and has since moved on to 2.12.0. All of these advisories were published in July 2026 or earlier, so naming them here discloses nothing new. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VUifZksSV3pi2zWxvs29ka
This is essentially special casing because in JSON a number value can be represented as a JSON number or as a JSON string. That behaviour comes from the fact that some older parsers would attempt to parse numbers as int32/64 or float32/64 and get out of bound exceptions when the number is larger than that. In practical sense if we see type int | string, we should consider that as a numeric type, and attempt to correlate with the format BEFORE we fall back to a string type. And if special casing is required in the code to avoid a regression, let's implement that. |
Per review feedback: int | string is what System.Text.Json's JsonNumberHandling.AllowReadingFromString advertises, the ASP.NET Core default, so the pair should resolve to the numeric type rather than collapsing to a string. The format is correlated first, and a string only wins when there is no numeric format to go on. This matches the rule GetPrimitiveType already applies for clients on main, backported here for the plugin path. Suite: 1967 passed, 0 failed, 2 skipped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VUifZksSV3pi2zWxvs29ka
|
Two things. First, a correction. My earlier claim here that the fold is specific to 2.12.0 and that 3.10.0 is unaffected was wrong. Both readers fold. I had been reading local test runs that reported green while the test host was crashing partway through, exit code -1073741571, with the runner still printing Nothing changes for this branch in practice. 2.12.0 is still the right target, we still need the narrowing, and CI here was green on the previous commit. The difference is only that the same fix belongs on main too, rather than main being naturally immune as I claimed. Second, your point about numeric unions is implemented. You are right that That also retires the caveat from my earlier comment. Suite here: 1967 passed, 0 failed, 2 skipped, |
|
Thank you for making the changes! I believe we need to go ahead with the version bump I was referring to here and we should be good to merge this. |
Ran scripts/bump-version.ps1 -kind patch and scripts/prepare-release.ps1 as requested, which moves the unreleased security entries under 1.29.1. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VUifZksSV3pi2zWxvs29ka
|
Done, Ran Two small things I reverted by hand, both side effects of the scripts rather than intended changes: Let me know if you would rather the release date be the actual merge date, I can amend. |
Vincent Biret (baywet)
left a comment
Vincent Biret (baywet)
left a comment
There was a problem hiding this comment.
Thank you for making the changes!
70cd8bc
into
microsoft:security/1-29-x
Fixes the codegen bug from microsoft/kiota#8038, now released as Microsoft.OpenApi.Kiota.Builder 1.29.1 (Microsoft.OpenApi 2.12.0). Verified via `Tests/IntegrationTests/FastEndpoints.OpenApi.Kiota` (client generation + command-mode export), which is otherwise excluded from CI. Claude-Session: https://claude.ai/code/session_016gczAbMsgW4deQYkFpxdTZ Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
3 participants
Fixes #7999. Security-only backport of fixes for
Kiota.BuilderCVEs ontov1.29.0, targetingsecurity/1-29-x. Nothing on theMicrosoft.OpenApi3.x line, so it doesn't conflict withMicrosoft.AspNetCore.OpenApistill being pinned to 2.x.Consumers stuck on 1.29.x because they can't take the OpenAPI v3 major bump yet (see #7999 and the FastEndpoints side of this, FastEndpoints/FastEndpoints#1101) currently have no way to clear
NU1903/NuGetAudit onKiota.Builderwithout pulling in an incompatible major. This branch is a proof that a 1.29.x-based patch is buildable and passes the full test suite, in case the team decides a backport is worth shipping.This started as a 3-CVE backport; querying the advisory database turned up 8 more disclosed CVEs affecting
Kiota.Builder, all confirmed present onv1.29.0by checking the actual pre-fix code, not just the advisory's version range. All 11 are now ported.What's in it
Dependency/CI:
8cc28ced9: GHSA-v5pm-xwqc-g5wc, bumpMicrosoft.OpenApi/Microsoft.OpenApi.YamlReader2.0.0 to 2.7.6. Same major, first patched version in the 2.x line. Blocked from release: needs another bump once chore(support/v2): release 2.12.0 OpenAPI.NET#2978 ships in a published NuGet version (not merged yet as of this writing, being watched).bd18b5d5c: adapts.azure-pipelines/ci-build.ymlto this branch's source tree (kiota.slnnot.slnx,net9.0notnet10.0,npm-package/runtime.jsonpath), pulling inmain's private-feed routing and release idempotency guards otherwise unchanged.d604dbd70: GHSA-4625-4j76-fww9, GHSA-mr8r-92fq-pj8p, GHSA-q834-8qmm-v933, bumpOpenTelemetry/OpenTelemetry.Exporter.OpenTelemetryProtocol/OpenTelemetry.Extensions.Hosting1.13.1 to 1.15.3. Unrelated to the Kiota CVEs, but was failing CI (NU1902) once the pipeline actually ran.f8660d8cb: removes leftover git conflict markers accidentally committed intoCHANGELOG.mdin an earlier commit on this branch.37b3f04e7: reorganizesCHANGELOG.md, moving all new entries under[Unreleased]and removing the[1.30.0]-[1.32.3]headings that describedmain's release history rather than this branch's.b661129df:dotnet formatacross the whole tree (250 files, whitespace/blank-line only, no behavioral changes).dotnet format --verify-no-changesis clean now.b61800293: fixes twois not A or Bpattern-matching precedence bugs (parses as(is not A) or B, not the intendedis not (A or B)) that a newer Roslyn flags as CS9336-redundant. Build no longer needs-p:NoWarn=CS9336.CVE fixes, security-only:
47cc7d9f9: GHSA-hq9q-27g5-qwpj, don't use the install command from the OpenAPI extension. Clean cherry-pick of fix: do not use the install command from the OpenAPI extension #7883.35ce7fa59: GHSA-4jwf-m4wg-8p66, reject unsafestatic_template.filereferences in plugin manifest generation. Backport of fix: reject unsafe static_template.file references in plugin manifest generation #7892, hand-ported against 1.29.0's plainJsonObject/string extension shape rather than the newer typedExtensionResponseSemanticsStaticTemplatemodel.6dbee0fd6: GHSA-2hx3-vp6r-mg3f / CVE-2026-41134, code generation literal injection across nearly every language writer. Backport of security: remote code execution with default/enum/literal values fix #7603, the original/largest fix this whole CVE batch stems from.e9223f274: GHSA-7f3j-j7jj-r3vr / CVE-2026-59862, Python literal injection viax-ms-enumdescription newlines. Backport of fix(writers/python): prevent code injection via x-ms-enum description #7735.02bbeb403: GHSA-xg2h-5xr2-29jw / CVE-2026-59861, Ruby literal injection via unescaped#interpolation. Backport of fix(ruby): escape interpolation markers in generated string literals #7746.952bdc39c: GHSA-3hrf-2gc2-mx32 / CVE-2026-59860, C# doc-comment newline breakout. Backport of fix(csharp): strip newlines from doc comment text to prevent code injection #7831.ceae0747f: GHSA-jqwh-526h-c92j / CVE-2026-59859, PHP literal injection via unescaped$interpolation. Backport of fix(php): Escape $ in double-quoted string literals to prevent code injection #7863.28bc8b746: GHSA-4vv7-jj25-4gh6 / CVE-2026-59866, unsanitizedclientClassName/clientNamespaceNamefromx-ms-kiota-info. Backport of fix: sanitizes the client class and namespace names to avoid code injection #7884.945516dd9: GHSA-4rj6-vrwv-wr8m / CVE-2026-59863, workspace-config output-path poisoning. Backport of fix: validate workspace output paths are sub-directories #7885.e96aca914: GHSA-rg4h-fpcp-2qm8 / CVE-2026-59867, SSRF via unrestricted$refresolution. Backport of feat: adds an allow list parameter for external references resolution #7888. Core library fix applies clean; the CLI wiring (13 files) was hand-ported against this branch's olderSystem.CommandLineAPI (InvocationContext/GetValueForOptionvs.main'sParseResult/GetValue).Conflicts against most upstream fixes were pure indentation drift or unrelated features this branch doesn't have (an intervening default-value formatting feature in Ruby, an
AllowedExternalOriginsOption-adjacentServiceProviderDI refactor, etc.), not semantic divergence. Details are in each commit message.Testing
AllowedExternalOriginsLoadMatchingReferenceshits aMicrosoft.OpenApi2.7.6 circular-reference resolution quirk in the test's mock fixture; the actualAllowedExternalOriginsStreamLoadersecurity logic and its other 8 dedicated tests all pass.AllowedExternalOriginsLoadMatchingReferencesgap above, anSSLConnection/network blip on a live-endpoint test (KiotaSearcherTests.GetsMicrosoftGraphBetaAsync), and 404s on external fixture URLs that moved/vanished (googlemaps/openapi-specification,msgraph-sdk-powershellfor the VS Code extension's jest suite, unrelated to any C# changes here).dotnet format --verify-no-changesand the CS9336 Roslyn warning, both previously flagged as pre-existing drift, are now fixed inb661129df/b61800293respectively.Open question
Is a 1.29.x security-only patch line something the team would take, or is
Microsoft.OpenApi3.x support inMicrosoft.AspNetCore.OpenApiclose enough that this isn't worth maintaining in parallel? Asked the same thing on #7999.Per Vincent Biret (@baywet)'s review: before merging/releasing, we need microsoft/OpenAPI.NET#2978 to ship in a published NuGet version so
Microsoft.OpenApi/Microsoft.OpenApi.YamlReadercan be bumped again. Watching for that.