> For the complete documentation index, see [llms.txt](https://docs.sonarsource.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sonarsource.com/sonarqube-server/2026.4/server-update-and-maintenance/release-notes.md).
# Release notes
These release notes describe the relevant changes implemented for SonarQube Server 2026.4. If you’re upgrading from the previous LTA, see the [2026.1 LTA to LTA release notes](https://docs.sonarsource.com/sonarqube-server/2025.4/server-update-and-maintenance/lta-to-lta-release-notes). For a complete list of all changes, see the [#full-release-notes](#full-release-notes "mention").
## New and enhanced features
View the release notes for new and enhanced features for SonarQube Server.
2026.4
### AI capabilities
#### *Sonar way for agentic AI* quality gate
A new built-in quality gate, *Sonar way for agentic AI*, provides quality standards tuned for agentic development workflows. Its conditions cover reliability, security, and maintainability severity on new code, plus new coverage, new duplication, and a dependency-risk condition, so high-risk changes are caught before they merge. The gate adapts its conditions automatically to the instance's active mode (Standard experience or MQR). The previous built-in *Sonar way for AI Code* becomes a custom quality gate for instances that were using it, keeping its existing conditions and project assignments intact. For more information, see [Quality gate for agentic AI](/sonarqube-server/2026.4/quality-standards-administration/ai-code-assurance/quality-gate-for-agentic-ai.md).
### Quality gate history
A new Quality gate history page shows how a project's quality gate verdict has evolved across released versions on the main branch. Each released version is marked safe (gate passed) or risky (gate failed) at release time, with a summary of safe versus risky releases and period filtering. The page helps teams monitor guard-rail adherence over time and spot high-risk releases. It requires the Previous version new code definition and is reachable by going to *your project* > **Quality gate history**. For more information, see [Quality gate history](/sonarqube-server/2026.4/quality-standards-administration/managing-quality-gates/quality-gate-history.md).
### Automated GitHub App creation
Connecting SonarQube Server to GitHub no longer requires manually creating a GitHub App and copying your credentials by hand. From **Administration** > **Configuration** > **General Settings** > **DevOps Platform Integrations**, administrators can launch a guided flow that uses a GitHub App Manifest to pre-configure the exact permissions, webhook, and callback URLs SonarQube needs. The feature automatically retrieves and saves the resulting App ID, client ID, client secret, and private key. The flow works with both GitHub.com and GitHub Enterprise Server, and falls back to manual setup when the automated handshake is not possible. For more information, see [Setting up a GitHub App](/sonarqube-server/2026.4/instance-administration/devops-platforms/github/setting-up-github-app.md).
### Severity-based quality gate conditions for new code
Quality gates can now use severity-based conditions on new code. New metrics expose the highest severity among new issues for each issue type in the Standard experience and for each software quality in MQR mode, so you can fail a quality gate when new code introduces an issue at or above a chosen severity. The metrics update live as issue severities change, without requiring a full re-analysis. For more information, see [Managing custom quality gates](/sonarqube-server/2026.4/quality-standards-administration/managing-quality-gates/managing-custom-quality-gates.md).
### Consistent new code fallback for reference branch analysis
When the Reference branch new code definition is used and SCM data is missing or invalid (for example, on a shallow clone or a repository without Git history), new code is now computed consistently across the first and subsequent analyses. SonarQube Server compares the current analysis against the last snapshot of the configured reference branch, falling back to the last snapshot of the main branch when the reference branch is not available. This removes the fluctuating new-code calculations that could previously appear between runs. For more information, see [Configuring new code calculation](/sonarqube-server/2026.4/project-administration/adjusting-analysis/configuring-new-code-calculation.md).
### Faster pull request analysis for large Java and C# projects
Incremental analysis in the taint engine significantly reduces pull request analysis time on large, complex Java and C# projects, where scans previously took the longest. Most projects already finish quickly and won't notice a difference, but on the slowest-scanning projects, pull request analysis is considerably faster.
### New MISRA C compliance quality profiles
Check your C code against the MISRA C guidelines with the new Sonar MISRA compliance quality profiles. Available in Enterprise edition and higher, each profile combines the Sonar way quality profile with rules mapped one-to-one to the matching MISRA C guidelines, giving you both Sonar and MISRA expertise in a single profile. The following profiles are now available:
* Sonar MISRA C:2012 Compliance
* Sonar MISRA C:2012 AMD1 + TC1 Compliance
* Sonar MISRA C:2012 AMD2 Compliance
* Sonar MISRA C:2012 AMD3 Compliance
* Sonar MISRA C:2023 Compliance
New rule tags (`misra-c-2012`, `misra-c-amd1-tc1`, `misra-c-amd2`, `misra-c-amd3`, and `misra-c-2023`) let you identify the corresponding rules and build custom MISRA C profiles from scratch. See [Understanding quality profiles](/sonarqube-server/2026.4/quality-standards-administration/managing-quality-profiles/understanding-quality-profiles.md) for more information.
### External issue import with overlapping start and end locations
The generic issue import format now accepts findings whose start column equals their end column. Such issues are imported and displayed correctly, expanding the highlight to the end of the line, so external reports that point to a single position in the code no longer fail to import. For more information, see [Generic formatted reports](/sonarqube-server/2026.4/analyzing-source-code/importing-external-issues/generic-issue-import-format.md).
### Software architecture analysis
The software architecture capability is now available in SonarQube Server. Architecture analysis runs on each scanner execution with no additional configuration and is included in all commercial editions (Developer edition and higher). It covers four areas:
* Current architecture: a visual model of how your project is structured and how its components depend on one another.
* Intended architecture: define which components may and may not depend on each other, and SonarQube raises deviations as standard issues.
* Deviations, flaws, and smells: structural problems such as tangles, oversized components, and split responsibilities are detected automatically.
* Remediation workflow: architecture issues follow the same triage and fix workflow as code quality issues, integrated with quality profiles and quality gates.
Supported languages are Java, C#, JavaScript, TypeScript, and Python. For more information, see [Architecture](/sonarqube-server/2026.4/architecture.md).
### IPv6 support for DCE Docker and Helm deployments
SonarQube Server Data Center Edition now supports IPv6-only and dual-stack network environments for both Docker and Kubernetes (Helm) deployments. The Docker entrypoint automatically discovers the node address across IPv4 and IPv6, and a new `SONAR_CLUSTER_NODE_HOST` environment variable lets you set a static IPv6 address on dual-stack networks where you want to run the DCE cluster exclusively over IPv6. The Helm chart works on IPv6-only and IPv6-primary dual-stack clusters without any chart-level configuration, using the pod's primary IP family as exposed by the Kubernetes downward API. For more information, see [Customizing the DCE Helm chart](/sonarqube-server/2026.4/server-installation/data-center-edition/on-kubernetes-or-openshift/customizing-helm-chart.md).
### EU Cyber Resilience Act security report
Available in Enterprise edition and higher.
A new EU Cyber Resilience Act (CRA) security report maps detected findings to the CRA requirements, and a corresponding entry is available in the Security Category facet. This helps teams demonstrate compliance with the EU CRA from within SonarQube Server. For more information, see [Cyber Resilience Act](https://docs.sonarsource.com/cyber-resilience-act).
### Advanced Security
Available as part of SonarQube Advanced Security license for [Enterprise](https://www.sonarsource.com/plans-and-pricing/sonarqube/) edition and higher.
#### Bulk actions for dependency risks
You can now select multiple dependency risks and update them as a group, applying a status change to many risks in a single action instead of one at a time. This speeds up triage when the same decision applies across several dependency risks. For more information, see [Reviewing and fixing dependency risks](/sonarqube-server/2026.4/advanced-security/reviewing-and-fixing-dependency-risks.md).
### Languages
> **Note**: Security hotspots rules are being changed to vulnerabilities (in Standard Experience) or security issues (in MQR Mode). Existing security hotspots remain visible on the Security Hotspots page.
#### Gosu (new)
SonarQube Server now supports Gosu, the language used with the Guidewire platform in the insurance sector. Support includes parsing, syntax highlighting, and metrics, along with an initial set of code quality rules.
New rules:
* S100: Function names should comply with a naming convention
* S101: Class names should comply with a naming convention
* S103: Lines should not be too long
* S104: Files should not have too many lines of code
* S105: Tabulation characters should not be used
* S107: Functions should not have too many parameters
* S108: Nested blocks of code should not be left empty
* S117: Local variable and function parameter names should comply with a naming convention
* S121: Control structures should use curly braces
* S122: Statements should be on separate lines
* S126: "if ... else if" constructs should end with "else" clauses
* S131: "switch" statements should have "default" clauses
* S134: Control flow statements "if", "for", "while", "switch" and "try" should not be nested too deeply
* S138: Functions should not have too many lines of code
* S1066: Mergeable "if" statements should be combined
* S1125: Boolean literals should not be redundant
* S1134: Track uses of "FIXME" tags
* S1135: Track uses of "TODO" tags
* S1143: Jump statements should not occur in "finally" blocks
* S1144: Unused "private" methods should be removed
* S1145: Useless "if(true) {...}" and "if(false){...}" blocks should be removed
* S1151: "switch case" clauses should not have too many lines of code
* S1172: Unused function parameters should be removed
* S1186: Functions should not be empty
* S1192: String literals should not be duplicated
* S1206: "equals" and "hashCode" should be overridden in pairs
* S1313: IP addresses should not be hardcoded
* S1451: Track lack of copyright and license headers
* S1479: "switch" statements should not have too many "case" clauses
* S1656: Variables should not be self-assigned
* S1764: Identical expressions should not be used on both sides of a binary operator
* S1821: "switch" statements should not be nested
* S2260: Gosu parser failure
* S3776: Cognitive Complexity of functions should not be too high
* S8708: URL validation should use established libraries instead of string operations
* S8711: String literals should be used with DisplayKey.get()
* S8712: Multiple "where()" calls should be combined into a single filter
* S8713: Deprecated "intersect()" methods should not be used
* S8724: BigDecimal and BigInteger should use literal suffixes
* S8725: Private variables should be prefixed with an underscore
* S8726: Public variables should start with an uppercase letter
* S8727: "new Date()" should not be used in Guidewire applications
* S8729: Use "hasMatch()" instead of "where().count()" when checking for element existence
* S8730: "@PostOnChange" annotations should specify a target property
* S8731: Query "select()" should specify columns instead of returning all fields
* S8734: Transaction bundles should not be committed explicitly inside "runWithNewBundle" blocks
* S8735: XML content should be logged instead of printed to standard output
* S8736: Trailing comments should be aligned within code blocks
* S8737: Comment syntax should match comment length
* S8738: Messaging plugin lifecycle event handlers should not be empty
* S8739: Properties should be used instead of getter/setter methods
* S8740: Threads should not be created manually in container-managed environments
For more information, see [Gosu](/sonarqube-server/2026.4/analyzing-source-code/languages/gosu.md).
#### C# and VB.NET
The .NET analyzer is updated across the cycle with a new rule and rule improvements.
New rule:
* S8717: Multiple "\[Key]" attributes should not be used to define a composite key
Examples of modified rules:
* S108: Nested blocks of code should not be left empty
* S1133: Deprecated code should be removed
* S1135: Track uses of "TODO" tags
* S2629: Logging templates should be constant
* S2696: Instance members should not write to "static" fields
* S3251: Implementations should be provided for "partial" methods
For more information, see [C#](/sonarqube-server/2026.4/analyzing-source-code/languages/csharp.md) and [VB.NET](/sonarqube-server/2026.4/analyzing-source-code/languages/vb-dotnet.md).
#### Java
The Java analyzer adds new rules across the cycle, including rules for the Java date and time APIs and rules covering Quarkus, JPA, and Bean Validation patterns. Analysis no longer fails when `sonar.java.binaries` is missing; a warning is logged instead.
New rules:
* S8220: Conversions between local and timezone-aware types should use explicit timezone handling
* S8688: Time-based .now() methods should specify a ZoneId or a Clock
* S8692: The system clock should not be used in unit tests
* S8694: DayOfWeek and Month Enums should be used instead of numeric values
* S8695: Redundant time instantiation patterns should be simplified
* S8696: Value-based types should be compared using their value
* S8700: Do not perform date and time arithmetic on DST unaware types
* S8908: Methods annotated with "@CacheResult" should not return void
* S8909: "CacheKeyGenerator" implementations should be instantiable by the framework
* S8910: Interfaces annotated with "@Mapper" should contain at least one "@DaoFactory" method
* S8911: Methods annotated with "@Startup" should be non-static, non-producer, and parameter-free
* S8912: Custom CredentialsProvider implementations should be annotated with "@Unremovable"
* S8913: REST Data with Panache resource interfaces should not have implementation classes
* S8947: JPA entity classes should not be final
* S8948: "@OneToMany" relationships should use "mappedBy" or "@JoinColumn"
* S8954: Bean Validation constraints should not be placed on static fields
For more information, see [Java](/sonarqube-server/2026.4/analyzing-source-code/languages/java.md).
#### JavaScript/TypeScript/CSS
The JavaScript and TypeScript analyzer adds `sonar-resolve` support and detection of generated code and ships new CSS rules. New rules also target testing practices, utility-library usage such as Lodash, and Vue.
New rules:
* S2925: No fixed waits in tests
* S5976: Similar tests should be grouped in a single Parameterized test
* S8782: Lifecycle hooks should be declared before test cases
* S8783: Forced browser interactions should not bypass actionability checks
* S8784: Assertions should be placed inside test cases or hooks
* S8785: Test suite callbacks should be synchronous functions
* S8907: Replace Lodash/underscore.js methods with native APIs
* S8927: Default imports from modular utility libraries should not be used
* S8950: Vue props with a default value should not be required
* S8951: Vue component props should not be mutated directly
* S8959: UI test debug commands should not be used
* S8961: Vue component events should be explicitly declared
* S8962: Vue ref and shallowRef calls should be typed
* S8967: Inline snapshots should not contain interpolations
For more information, see [JavaScript/TypeScript/CSS](/sonarqube-server/2026.4/analyzing-source-code/languages/javascript-typescript-css.md).
#### Python
The Python analyzer adds new rules for testing, the Pydantic library, and web scraping with Beautiful Soup, and reduces false positives. Issues classified as main-code issues are no longer raised on test files.
New rules:
* S2187: Test files should contain at least one test case
* S3415: Assertion arguments should be passed in the correct order
* S5778: Only one method invocation is expected when testing runtime exceptions
* S5779: Assertions should not be made within the try block of a try-except catching AssertionErrors
* S5863: Assertions should not be given twice the same argument
* S5958: Tests should check which exception is thrown
* S5976: Similar tests should be grouped in a single Parameterized test
* S8714: Dedicated exception assertions should be used instead of "try-catch" with "fail()"
* S8900: Deprecated Beautiful Soup methods should be replaced with their modern equivalents
* S8903: HTML elements should be created with "new\_tag()" instead of inserting raw HTML strings
* S8904: BeautifulSoup elements should be checked for None before accessing
* S8905: BeautifulSoup parser should be explicitly specified
* S8906: CSS selectors should be used when selecting elements with multiple required classes
* S8963: Pydantic models should not use multiple inheritance with conflicting configurations
* S8966: pydantic-core serialization calls should provide fallback handlers
* S8971: "SkipValidation" should not be combined with validation constraints
* S8973: Double leading underscores should not be used for private attributes in Pydantic models
* S8974: "json\_schema\_input\_type" should not be used with "mode='after'" field validators
For more information, see [Python](/sonarqube-server/2026.4/analyzing-source-code/languages/python.md).
#### HTML
A new rule lets you enforce the HTML `lang` attribute against a configured list of allowed language codes.
New rule:
* S8687: Enforce the HTML "lang" attribute against a configured list of ISO 639-1 language codes
For more information, see [HTML](/sonarqube-server/2026.4/analyzing-source-code/languages/html.md).
#### PL/SQL and T-SQL
PL/SQL and T-SQL properties are now grouped under a shared SQL category in the configuration UI. For more information, see [PL/SQL](/sonarqube-server/2026.4/analyzing-source-code/languages/pl-sql.md) and [T-SQL](/sonarqube-server/2026.4/analyzing-source-code/languages/t-sql.md).
#### PostgreSQL (new)
SonarQube Server now analyzes the PostgreSQL SQL dialect, including PL/pgSQL, and ships an initial set of rules covering correctness, security, and maintainability of PostgreSQL code.
New rules:
* S8788: Set-returning functions should terminate with a bare "RETURN" after "RETURN NEXT" or "RETURN QUERY"
* S8933: Composite primary keys should not contain more than four columns
* S8934: Schemas should not grant the CREATE privilege to PUBLIC
* S8935: Format strings should have properly terminated conversion specifiers
* S8937: Format placeholders in "format()" should use 1-based indexing
* S8938: Indirect-width format specifiers should include a dollar sign after the width position
* S8939: PL/pgSQL protected automatic variables should not be modified
* S8942: Identifiers should not use reserved SQL keywords
* S8943: Unused arguments in PostgreSQL "format()" calls should be removed
* S8944: PostgreSQL "format()" calls should provide enough arguments for all placeholders
* S8945: Transaction control statements should not be used inside exception handling blocks
For more information, see [PostgreSQL](/sonarqube-server/2026.4/analyzing-source-code/languages/postgres.md).
#### Secrets
The following improvements have been made:
* The list of file extensions excluded from secret detection, previously hard-coded, is now customizable.
* Test-file detection, performance, and logging have been improved.
The known-fake-secret filter discards secret candidates that match a rule's list of fake or placeholder values (repeated characters, placeholder tokens, documentation examples). The new sonar.secrets.disableKnownFakeSecretFilter property (default false) turns this filter off when set to true, reporting those candidates as low-confidence matches, which is useful when evaluating secret detection on a benchmark project. For more information, see [Secrets](/sonarqube-server/2026.4/analyzing-source-code/languages/secrets.md).
#### Infrastructure as Code
The Infrastructure as Code analyzer improves file-predicate handling with a new cache and adds new rules, including new Logic Apps rules for Azure Resource Manager.
New rules:
* S8793: RDS database instances should not be publicly accessible
* S8847: Azure Key Vaults should enable purge protection
* S8857: GCP Cloud Storage buckets should enforce uniform bucket-level access
2026.3
### AI capabilities
#### Embedded Model Context Protocol (MCP) for SonarQube Server
SonarQube Server can now host a SonarQube MCP server as an extension, exposing a `/mcp` reverse-proxy endpoint that lets AI coding agents (Claude, Cursor, Copilot, and others) query your SonarQube Server instance directly. The hosted MCP server is installed on SonarQube Server, simplifying management by requiring only a single MCP server URL to access.
Administrators can toggle the server, configure the upstream URL, and tune health-check behavior through `sonar.mcp.*` properties in your `sonar.properties` file. Health-check status is surfaced through the standard SonarQube Server monitoring endpoints. See the MCP server [https://docs.sonarsource.com/sonarqube-developer-tools/sonarqube-mcp-server/setup/sonarqube-server-hosted](https://docs.sonarsource.com/sonarqube-developer-tools/sonarqube-mcp-server/setup/sonarqube-server-hosted "mention") page for more information.
#### Sonar agentic AI quality profile
A new built-in quality profile, **Sonar agentic AI**, is now available for Java, JavaScript/TypeScript, and Python. The profile selects rules tuned for code produced by AI coding agents, focusing on the failure modes and recurring patterns most often introduced by agentic workflows.
### Monitoring alerts for SonarQube Server administrators
Monitoring alerts help system administrators detect performance problems in a SonarQube Server instance. They surface signs of degraded behavior early, so administrators can investigate before users start reporting slow or failed analysis results. Their purpose is to show that the instance is experiencing a performance problem and that administrator attention is needed. See [Monitoring alerts](/sonarqube-server/server-update-and-maintenance/monitoring/monitoring-alerts.md) for more information.
### GitLab authentication and provisioning improvements
This major overhaul removes critical friction points for large-scale enterprise GitLab customers with tens of thousands of users and projects. It officially maps the new GitLab Planner and Security Manager roles to SonarQube's default Reporter permissions. It also vastly optimizes GitLab JIT provisioning times and provides a new **Allow all groups** option.
### Configurable server-side cache expiration
The expiration duration for the server-side cache used for faster PR analysis is now configurable, allowing instances to tune cache lifetimes to match their analysis cadence and infrastructure. Set the number of days for the `sonar.dbcleaner.daysBeforeDeletingScannerCache` property in the SonarQube Server UI at **Administration > General Settings > Housekeeping**.
### Improved license renewal experience
Licenses issued for a specific edition remain valid for all editions below that licensed tier, so you have time to upgrade when renewing or changing your SonarQube Server edition. See [License administration](/sonarqube-server/instance-administration/license-administration.md) for more information.
### Advanced Security
Available as part of SonarQube Advanced Security license for [Enterprise](https://www.sonarsource.com/plans-and-pricing/sonarqube/) edition and higher.
#### Vulnerability Exploitability Exchange (VEX) export
Generate and download vulnerability reports in the CycloneDX 1.6 VEX format. This extends existing risk reporting by automatically compiling a list of vulnerabilities affecting a project or portfolio, translating their current status from dependency risk metrics, and pulling in the specific engineering justifications based on status-change comments. See [Reviewing and fixing dependency risks](/sonarqube-server/advanced-security/reviewing-and-fixing-dependency-risks.md) for more information.
#### Change in scope of Software Bills of Materials
Starting with SonarQube Server 2026.3, Software Bills Of Materials (SBOMs) generated by SonarQube Advanced Security only include production dependencies or dependencies that end up in your released application by default. If you need to include all dependencies, including development dependencies, you can generate a SBOM via the API by passing `onlyProductionScope=false`.
### Languages
#### C\#
Four new rules help teams adopt C# 14 cleanly by flagging identifier conflicts with the new contextual keywords. See [C#](/sonarqube-server/analyzing-source-code/languages/csharp.md) for more information.
New rules:
* S8367: Identifiers should not conflict with the "field" keyword in C# 14
* S8368: "extension" identifiers should be escaped to avoid contextual keyword conflicts
* S8380: Return types named "partial" should be escaped with "@"
* S8381: "scoped" should be escaped when used as a type name in lambda parameters
**Cobertura coverage format for C#**
The C# analyzer now accepts Cobertura-formatted coverage reports, passed via the `sonar.cs.cobertura.reportsPaths` parameter. This complements the existing dotCover, OpenCover, and Visual Studio coverage formats and removes the need to convert Cobertura output before importing it. See [.NET test coverage](/sonarqube-server/analyzing-source-code/test-coverage/dotnet-test-coverage.md) for more information.
#### Go
Go test files are now analyzed only by checks applicable to test files, removing irrelevant findings on `_test.go` files. See [Go](/sonarqube-server/analyzing-source-code/languages/go.md) for more information.
#### Groovy
New Groovy rules ship in this release: 17 for the core Groovy language and 23 specific to Jenkins pipelines. See [Groovy](/sonarqube-server/analyzing-source-code/languages/groovy.md) for more information.
New rules for the Groovy language:
* S107: Functions should not have too many parameters
* S122: Statements should be on separate lines
* S126: "if ... else if" constructs should end with "else" clauses
* S134: Control flow statements "if", "for", "while", "switch" and "try" should not be nested too deeply
* S138: Functions should not have too many lines of code
* S1067: Expressions should not be too complex
* S1125: Boolean literals should not be redundant
* S1134: Track uses of "FIXME" tags
* S1135: Track uses of "TODO" tags
* S1145: Useless "if(true) {...}" and "if(false){...}" blocks should be removed
* S1151: "switch case" clauses should not have too many lines of code
* S1192: String literals should not be duplicated
* S1479: "switch" statements should not have too many "case" clauses
* S1821: "switch" statements should not be nested
* S1862: Related "if-else if" statements should not have the same condition
* S3923: All branches in a conditional structure should not have exactly the same implementation
* S4663: Multi-line comments should not be empty
New rules for Jenkins pipelines:
* S8327: Jenkins pipeline scripts should use pipeline steps instead of direct file I/O operations
* S8351: Input statements should be wrapped with timeouts and placed outside agent blocks
* S8353: Pipeline parameters should not use environment variables in default values
* S8355: Variables containing complex objects should not be declared in environment blocks
* S8356: Pipeline parameter definitions should not reference locally-defined environment variables
* S8357: Methods should use @NonCPS annotation to avoid CPS transformation issues
* S8358: Pipeline steps should not be called from "@NonCPS" methods
* S8359: Methods with closure parameters should not have ambiguous overloads
* S8360: "getItemByFullName" should be used to access Jenkins jobs in folders
* S8361: String split results should not be accessed by index without bounds checking
* S8364: JUnit step should specify test results file pattern
* S8365: Temporary files should be deleted after use in Jenkins pipelines
* S8366: Script-level variables should use "@Field" annotation instead of binding variables
* S8524: Try-catch blocks should be wrapped in "script" blocks in declarative pipelines
* S8525: Scripted code should be wrapped in "script" blocks within declarative pipeline stages
* S8526: SCM checkouts should use dedicated steps instead of shell commands with credentials
* S8527: "credentials()" should be used instead of "withCredentials" in environment sections
* S8531: Declarative and Scripted Pipeline syntax should not be mixed
* S8535: Groovy script strings should not be duplicated
* S8536: Jenkins parallel steps should use named arguments
* S8538: PATH modifications in "environment" blocks should use "$PATH" instead of "${env.PATH}"
* S8539: Choice parameters should be passed as strings when calling Jenkins jobs
* S8540: GitHub source blocks in Jenkins multibranch pipelines should include an explicit "id" field
#### Java
The Java analyzer ships a new rule alongside bug fixes and stability improvements. See [Java](/sonarqube-server/analyzing-source-code/languages/java.md) for more information.
New rule:
* S3706: "stream" should not be used for Collection "forEach" calls
#### JavaScript/TypeScript
One rule has been deprecated. See [JavaScript/TypeScript/CSS](/sonarqube-server/analyzing-source-code/languages/javascript-typescript-css.md) for more information.
Deprecated rule:
* S5042: Expanding archive files should not be done without controlling resource consumption
#### Package manager analyzer
New rules detect missing lock files across multiple languages:
* S8564–S8571: (JavaScript, Python, Go, PHP, Ruby, Java and Kotlin, Rust, Dart) dependency lock file should be committed to source control
New rule that detects Unicode Variation Selectors:
* S8522: Consecutive Unicode Variation Selectors should not be used
#### PHP
One rule has been deprecated. See [PHP](/sonarqube-server/analyzing-source-code/languages/php.md) for more information.
Deprecated rule:
* S4828: OS processes should not be signaled without validation
#### PowerShell
SonarQube Server now includes coverage of PowerShell scripts. See [PowerShell](/sonarqube-server/analyzing-source-code/languages/powershell.md) for more information.
New rules:
* S3776: Cognitive Complexity of functions should not be too high
* S8429: Cmdlets should be invoked with all mandatory parameters
* S8620: Lines should not end with trailing whitespace
* S8621: Pipeline statements spanning multiple lines should use consistent indentation
* S8622: "!" should not be used for logical negation
* S8624: "HelpMessage" parameter attributes should not be null or empty
* S8625: Functions should not shadow built-in PowerShell cmdlets
* S8626: Automatic variables should not be assigned to
* S8628: Hash algorithms MD5 and SHA-1 should not be used
* S8631: Parameter sets should have at most one parameter accepting pipeline input by value
* S8633: DSC resource functions should have identical parameters
* S8634: DSC resources should implement all required functions
* S8637: Reserved common parameters should not be redefined in advanced functions
* S8638: Deprecated WMI cmdlets should not be used
* S8640: Switch parameters should not default to "$true"
* S8641: "$null" should be placed on the left side of comparison operators
* S8642: Cmdlets, parameters, keywords, and operators should use consistent casing
* S8647: Credentials should not be sent over unencrypted connections
* S8649: Cmdlet aliases should not be used in scripts
* S8652: Credential parameters should use the PSCredential type
* S8653: DSC class "Test" methods should return boolean values
* S8657: Catch blocks should not be empty
* S8659: "Invoke-Expression" should not be used
* S8661: Parameters should have only one type specifier
* S8664: Mandatory parameters should not have default values
* S8666: Lines should not end with a backtick followed by whitespace
* S8667: Module manifests should use "RootModule" instead of deprecated "ModuleToProcess"
* S8669: DSC class "Set" methods should return void
* S8672: Functions accepting pipeline input should use a "process" block
* S8673: Computer names should not be hardcoded
* S8675: Function and cmdlet names should not use reserved words or reserved characters
* S8677: Functions should not use "Write-Host" unless they use the "Show" verb
#### Python
**Python collections rules**
New rules for Python collections target readability, correctness, and performance issues, guiding teams toward more idiomatic constructs such as `min()` and `max()`, direct membership tests on dictionaries, `next(iter(...))`, `itertools.chain.from_iterable(...)`, distinct loop variables, and simpler set operations. See [Python](/sonarqube-server/analyzing-source-code/languages/python.md) for more information.
New rules:
* S8492: "set.discard()" should be used instead of checking membership before removal
* S8493: "StopIteration" should not be raised inside generators
* S8503: Membership tests should not use empty collections
* S8510: Loop variables should not be reused in nested loops
* S8512: Class fields should not be defined multiple times
* S8517: "sorted()" should not be used with indexing to find minimum or maximum values
* S8519: "list(...)\[0]" should not be used to get the first element
* S8520: "sum()" should not be used with an empty list to concatenate lists
* S8521: Dictionary membership tests should not explicitly call ".keys()"
**Python object-oriented programming rules**
Seven new rules target common object-oriented pitfalls, helping teams catch broken inheritance hierarchies, unsafe dataclass defaults, incomplete comparison logic, missing property returns, invalid `__slots__` assignments, duplicate base classes, and inconsistent tuple-return contracts. See [Python](/sonarqube-server/analyzing-source-code/languages/python.md) for more information.
New rules:
* S8494: Attributes should only be assigned if they are declared in "slots"
* S8495: Functions should return tuples of consistent length
* S8500: Comparison methods should be defined completely
* S8504: Property methods should have a return statement
* S8509: Classes should not inherit from the same base class multiple times
* S8511: Multiple inheritance should not create Method Resolution Order (MRO) conflicts
* S8514: Dataclass attributes should use type annotations and "default\_factory" for mutable defaults
**Python data structures and operations rules**
Five new rules focused on data structures and operations help teams catch subtle but high-impact bugs around enums, dataclasses, dispatch decorators, shared mutable defaults, and iterator reuse. See [Python](/sonarqube-server/analyzing-source-code/languages/python.md) for more information.
New rules:
* S8505: @singledispatch and @singledispatchmethod should not be confused
* S8508: Mutable default values should not be used with dict.fromkeys() or ContextVar()
* S8516: Group iterators from itertools.groupby should not be reused
* S8685: Function calls should not be used as default values in dataclass attributes
#### RPG
Four new RPG rules ship in this release. The analyzer now supports multiline issues, allowing single findings to span more than one line of code. See [RPG](/sonarqube-server/analyzing-source-code/languages/rpg.md) for more information.
New rules:
* S1896: "INZ()" should not be used on module-level standalone fields in TSR programs
* S2033: Library names should not be hard-coded
* S2284: Calculations should use free-form syntax
* S2794: Result data structures should be used for file I/O
#### Ruby
Ruby analysis has been improved, delivering enhanced analysis performance. See [Ruby](/sonarqube-server/analyzing-source-code/languages/ruby.md) for more information.
#### Rust
The Rust analyzer now supports the following Clippy rules when importing a Clippy report. See [Rust](/sonarqube-server/analyzing-source-code/languages/rust.md) for more information.
Supported Clippy rules:
* disallowed\_fields
* duration\_suboptimal\_units
* manual\_checked\_ops
* manual\_take
* unnecessary\_trailing\_comma
#### Infrastructure as Code
The IaC analyzer adds multi-document Helm chart support and improves Bicep parsing. A new set of supply-chain-focused rules for Shell, Docker, Azure Pipelines, and GitHub Actions covers risky package-manager and CI patterns. See [Supported languages](/sonarqube-server/analyzing-source-code/languages/overview.md) for more information.
Example new rules:
* S6505: Allowing shell scripts execution during package installation is security-sensitive
* S7694: Swift dependencies should be locked to verified versions
* S8482: Avoid executing downloaded artifacts without verification
* S8531: Declarative and Scripted Pipeline syntax should not be mixed
* S8543–S8550: (JavaScript, Python, Go, PHP, Ruby, Java and Kotlin, Rust, Dart) dependencies should be locked to verified versions
2026.2
### New layout and navigation for SonarQube Server
The SonarQube Server UI has a refreshed layout and navigation. The horizontal top menu has been replaced with an intuitive vertical sidebar, introducing a new context switcher that allows users to instantly jump between enterprises, organizations, portfolios, and projects without losing their place.
### In-code issue resolution (`sonar-resolve`)
New in-code annotations let you resolve specific issues by rule, with a mandatory comment and status (accepted or false positive), so deviations stay visible in SonarQube’s UI and auditable rather than being blindly suppressed. This structured alternative to `NOSONAR` helps teams comply with standards such as MISRA C++:2023 and reduces the risk of accidentally hiding critical issues on the same line. See [Editing issues](/sonarqube-server/2026.2/user-guide/issues/managing.md) for more information.
**Key Capabilities**:
* Set resolution status (accept or fp for false-positive) directly in the code.
* Administrative control via global and project-level settings.
**Supported languages**: C, C++, Objective-C
### AI CodeFix enhancements
Improvements to AI CodeFix configuration to make it model-agnostic, enabling better flexibility in AI-powered code fix suggestions. This feature is available in [Enterprise](https://www.sonarsource.com/plans-and-pricing/sonarqube/) edition and higher.
### License management improvements
SonarQube Server now automatically refreshes SonarQube license every 12 hours for instances using online activation, ensuring immediate access to new features and LOC limit updates without manual intervention. See [Online license management](/sonarqube-server/2026.2/instance-administration/license-administration/online-license-management.md) for details.
### Advanced Security
Available as part of SonarQube Advanced Security license for[ Enterprise](https://www.sonarsource.com/plans-and-pricing/sonarqube/) edition and higher. See Advanced Security for more information. See [Introduction](/sonarqube-server/2026.2/advanced-security/introduction.md) to Advanced Security for more information.
#### Dependency risks in security reports
Sonar security reports now include a Dependency risk column. This weaves Software Composition Analysis (SCA) data directly into application and portfolio-level reports in both the SonarQube Server UI and exported PDFs. See [Security reports](/sonarqube-server/2026.2/user-guide/viewing-reports/security-reports.md) for details.
#### Risk report and SBOM in regulatory reports
Project regulatory reports now include both a risk report and a software bill of materials SBOM that you can download from your projects. See [Regulatory reports](/sonarqube-server/2026.2/user-guide/viewing-reports/regulatory-reports.md) for details.
#### ASAST Configurations for the Python Top 1K
We are expanding Advanced Static Application Security Testing (ASAST) support with the top 1,000 most utilized libraries in the Python ecosystem.
### Languages
#### Apex code quality rules
SonarQube Server 2026.2 expands Apex support with 23 new code quality rules, providing enhanced coverage for Salesforce developers. Apex support is available in [Enterprise](https://www.sonarsource.com/plans-and-pricing/sonarqube/) edition and higher. See [Apex](/sonarqube-server/2026.2/analyzing-source-code/languages/apex.md) for more information.
* S1213: The members of an interface or class declaration should appear in a pre-defined order
* S1659: Multiple variables should not be declared on the same line
* S7951: Database SaveResult objects should be checked for errors
* S7965: Future methods should not accept sObjects or custom objects as parameters
* S7972: Apex cursor fetch should use small chunk sizes to avoid governor limits
* S7994: AuraEnabled methods should be static when they don't require instance state
* S7999: Email operations should include proper error handling
* S8000: Test classes should create required test data within the test
* S8001: SOQL LIKE clauses should not use leading wildcards
* S8008: Encryption keys should not be hardcoded
* S8020: Server actions that retrieve data should be marked as cacheable
* S8028: Future methods should not be called from batch or queueable contexts
* S8032: Database.Stateful should only be used when state retention is needed
* S8035: Change Data Capture event objects should follow the correct naming convention
* S8041: Apex callouts should implement retry logic for reliability
* S8044: FormulaEval.FormulaBuilder should be properly configured with null checks, type safety, and return type
* S8125: Field-level permissions should be checked before accessing fields
* S8130: Retired Salesforce API versions should not be used
* S8451: Schema describe operations should not be called inside loops
* S8452: Classes should override both equals and hashCode or neither
* S8453: Test assertions should include descriptive messages
* S8455: SObject describe calls should use deferred loading
* S8456: Annotations should use PascalCase naming convention
#### Improved Go analyzer performance
Go analyzer is now 30 times faster. New rules include the same rules as listed for Apex above.
#### Java 25 support
SonarQube 2026.2 introduces error-free parsing and deep semantic analysis for Java 25 LTS, the first long-term support release since JDK 21. We've added critical rules targeting new features like Scoped Values (JEP 506), Flexible Constructor Bodies (JEP 513), and Module Imports (JEP 511). Crucially, these rules are designed to catch syntactically valid but semantically broken code generated by AI assistants trained on outdated preview APIs. See [Java](/sonarqube-server/2026.2/analyzing-source-code/languages/java.md) for more information.
Examples of new rules:
* S1128: Redundant imports should be removed
* S3051: Main methods should be used only as program entry point
* S8432: "ScopedValue.where" results should not be ignored
* S8433: Validation logic should be placed in constructor prologue when possible
* S8444: Validation and data preparation logic before super() should not bloat constructor
* S8445: Group import declarations by specificity
* S8446: Only one "main" method should be present
* S8447: Initialize subclass fields before super() when superclass constructor may call overridable methods
* S8450: Use IO.readln() for console input instead of BufferedReader boilerplate
* S8465: "ScopedValue" instances should be assigned to a stable reference
* S8469: Use IO.readln(String prompt) instead of IO.print followed by IO.readln()
#### JavaScript / TypeScript security rules
Six new security rules have been added for JavaScript / TypeScript. See [JavaScript/TypeScript/CSS](/sonarqube-server/2026.2/analyzing-source-code/languages/javascript-typescript-css.md)
* S5335: Imports should not be vulnerable to injection attacks
* S6547: Environment variables should not be defined from untrusted input
* S5496: Server-side templates should not be vulnerable to injection attacks
* S6641: Connection strings should not be vulnerable to injection attacks
* S6549: Accessing files should not lead to filesystem oracle attacks
* S7518: Privileged prompts should not be vulnerable to injection attacks
#### Kotlin 2.3.10 support
Upgraded the Kotlin analyzer for version 2.3.10 support.
#### Python
**Python Django framework rules**
New rules specifically targeting Django best practices and common pitfalls for web developers. See [Python](/sonarqube-server/2026.2/analyzing-source-code/languages/python.md) for more information.
Rules added:
* S8437: Class-Based Views should override "get\_context\_data" correctly
* S8438: Django view functions should declare URL parameters explicitly
* S8439: Django view functions should include all URL parameters in their signature
* S8440: Querysets should use "select\_related()" or "prefetch\_related()" to avoid N+1 queries
* S8443: Django Command classes should inherit from BaseCommand
* S8486: Django middleware should call super().init() with appropriate parameters
**Python Flask rules**
Flask services get dedicated rules to harden configuration, routing, and error handling, focusing on security and correctness of HTTP behavior. See [Python](/sonarqube-server/2026.2/analyzing-source-code/languages/python.md) for more information.
Related rules:
* S6863: Flask error handlers should set HTTP status code
* S6965: Flask REST API actions should be annotated with an HTTP verb attribute
* S8370: Query parameters should not be used to carry body data in POST requests
* S8371: HTTP headers should be accessed safely to avoid KeyError
* S8374: Flask class-based view decorators should be applied using the decorators attribute
* S8375: Flask preprocess\_request() return values should be handled
* S8385: send\_file should specify mimetype or download\_filename
* S8388: Flask applications should not bind to all network interfaces
**Python FastAPI rules**
FastAPI projects now get framework‑aware rules around routing, Pydantic models, dependencies, and documentation, aimed at catching typical FastAPI mistakes early. See [Python](/sonarqube-server/2026.2/analyzing-source-code/languages/python.md) for more information.
Related rules:
* S8389: File upload endpoints should use Form() with Pydantic
* S8392: FastAPI applications should not bind to all network interfaces
* S8396: Optional Pydantic fields should have explicit default values
* S8397: FastAPI applications should be passed as import strings when using reload
* S8400: Endpoints returning 204 should have an empty body
* S8401: Child routers should be included before parent router registration
* S8405: TestClient requests should use the content parameter
* S8409: Endpoints should not specify redundant response\_model parameters
* S8410: Dependencies should use Annotated type hints
* S8411: Path parameters should be included in route function signatures
* S8412: Generic route decorators should not be used
* S8413: Router prefixes should be defined during APIRouter initialization
* S8414: CORSMiddleware should be added last in the middleware chain
* S8415: HTTPException responses should be documented in endpoint metadata
#### Groovy language support (beta)
Initial support for Groovy language with 30+ code quality rules, enabling analysis of Groovy-based build files and scripts. See [Groovy](/sonarqube-server/2026.2/analyzing-source-code/languages/groovy.md) for more information.
Related rules:
* S8289: File operations should specify charset encoding
* S8298: "@TimedInterrupt" should not be used on static methods
* S8299: AST transformation classes should be annotated with "@CompileStatic"
* S8322: Simple "@Grab" annotations should use shorthand notation
* S8268: Thread.sleep() should not be used in loops for busy waiting
* S8287: Test methods should contain assertions
* S8323: Property names should use camelCase
* S8314: Static imports should appear before regular imports
* S8309: Use appropriate sorting methods to avoid mutation confusion
* S8285: Method names should follow camelCase naming conventions
* S8269: "wait()" calls should be inside "while" loops
* S8315: Empty strings should not be used for type conversion
* S8308: Elvis operator should be used for null-safe operations and ternary simplification
* S8304: Duplicate import statements should be removed
* S8275: Null checks should use correct logical operators
* S8320: GString expressions should not be used as map keys
* S8326: Range methods should be used appropriately
* S8311: Method names should not use reserved keywords
* S8272: Classes with a "clone()" method should implement "Cloneable"
* S8303: Star imports should be replaced with explicit imports
* S8307: Semicolons should be omitted in Groovy
* S8306: Control structures should use braces
#### Ruby (beta)
There are eight ruby rules in beta and two that have been removed. See [Ruby](/sonarqube-server/2026.2/analyzing-source-code/languages/ruby.md) for more information.
New beta rules:
* S8418: Unused method and block parameters should be removed or prefixed with underscore
* S8419: Function parameters should not be immediately reassigned
* S8421: Underscore-prefixed variables should not be used
* S8422: Trailing underscores in multiple assignment should be removed
* S8423: Parameter default values should not reference themselves
* S8424: Constants should not be reassigned
* S8425: Constants should be explicitly scoped to avoid ambiguous resolution
* S8426: Variables should not be assigned only to be implicitly returned
Removed rules
* S1854: Unused assignments should be removed
* S7819: Variables and methods should be accessible in their usage context
2026.1
### AI and mobile compliance reporting
Extends our regulatory coverage to include critical AI and Mobile security standards such as OWASP Top 10 for LLM and OWASP MASVS for project security reports. This feature is available in the [Enterprise](https://www.sonarsource.com/plans-and-pricing/sonarqube/) edition and above. See [Security-related rules](/sonarqube-server/2026.1/quality-standards-administration/managing-rules/security-related-rules.md) for more information.
### Feedback mechanism for self-hosted LLMs
Improves the success rate of generating valid AI CodeFix suggestions from self‑hosted LLMs.
### JFrog Evidence Collection with SonarQube Server
This integration provides a single, verifiable audit trail if you use both SonarQube and JFrog with strict audit trail and compliance requirements. SonarQube analysis results are automatically signed and directly attached to your JFrog packages to create a single, verifiable source of truth. You no longer have to jump between tools to prove your code meets security standards. Everything you need for a rigorous audit is now visible within the JFrog Evidence Collection interface. This feature is available in the [Enterprise](https://www.sonarsource.com/plans-and-pricing/sonarqube/) edition and above. See [JFrog Evidence Collection](/sonarqube-server/2026.1/discovering/integrations/jfrog.md) for more information.
### SonarQube Advanced Security
This feature is available in the [Enterprise](https://www.sonarsource.com/plans-and-pricing/sonarqube/) edition and above.
**Malicious package detection**
Receive blocker-level alerts if a dependency matches publicly known datasets of known malicious packages. See [Advanced Security](/sonarqube-server/2026.1/advanced-security.md) for more information.
### Quality gate fudge factor improved
To avoid overly strict enforcement of small changes, the quality gate ignores coverage and duplication conditions for very small sets of new code. See [Changing instance's default quality gate](/sonarqube-server/2026.1/quality-standards-administration/managing-quality-gates/changing-default-quality-gate.md) for more information.
### Languages
**Cobol**
Adds support for parsing additional language constructs and includes fixes for crashes and false positives for [COBOL](/sonarqube-server/2026.1/analyzing-source-code/languages/cobol.md). Related rules include:
* S3938: Track uses of forbidden statements
* S1725: Open files should be closed explicitly
* S1574: Data items should be initialized with data of the correct type
* S1289: Unused data item blocks should be removed
**IaC**
The analysis of Infrastructure as Code (Ansible, Azure Resource Manager, CloudFormation, Docker, Kubernetes, Terraform, Shell, GitHub Actions) has been improved.
Helm templates are now evaluated even if values.yaml is missing.
The following rules have been added:
* S6437: Credentials should not be hard-coded
* S7638: ACTIONS\_ALLOW\_UNSECURE\_COMMANDS should not be used
* S8232: Workflows should not rely on unverified GitHub context values to trust events
* S8233: Write permissions should be defined at the job level
* S8262: Artifacts should not contain secrets
* S8263: GitHub Action invocations should not be vulnerable to parameter injection attacks
* S8264: Read permissions should be defined at the job level
**JCL**
A new `leaveFile` API is available for custom rules for [JCL](/sonarqube-server/2026.1/analyzing-source-code/languages/jcl.md) language, giving rule authors more control over how files are processed and reported.
**.NET 10 and C# 14 support**
Empowers .NET teams to adopt the Long Term Support (LTS) release of .NET 10 and C# 14 immediately, ensuring their analysis remains accurate, performant, and free of false positives associated with new language constructs. See [VB.NET](/sonarqube-server/2026.1/analyzing-source-code/languages/vb-dotnet.md) and [C#](/sonarqube-server/2026.1/analyzing-source-code/languages/csharp.md) for more information.
Related rules:
* S1121: Assignments should not be made from within sub-expressions
* S1144: Unused private types or members should be removed
* S2225: "ToString()" method should not return null
* S2292: Trivial properties should be auto-implemented
* S2325: Methods and properties that don't access instance data should be static
* S2583: Conditionally executed code should be reachable
* S2589: Boolean expressions should not be gratuitous
* S2692: "IndexOf" checks should not be for positive numbers
* S2953: Methods named "Dispose" should implement "IDisposable.Dispose"
* S2970: Assertions should be complete
* S3063: "StringBuilder" data should be used
* S3264: Events should be invoked
* S3398: "private" methods called only by inner classes should be moved to those classes
* S3459: Unassigned members should be removed
* S3877: Exceptions should not be thrown from unexpected methods
* S3928: Parameter names used into ArgumentException constructors should match an existing one
* S4545: "DebuggerDisplayAttribute" strings should reference existing members
* S7039: Content Security Policies should be restrictive
**PHP**
Reduces false positives on several rules and cleans up build and dependency infrastructure for [PHP](/sonarqube-server/2026.1/analyzing-source-code/languages/php.md). Related rules:
* S1155: "empty()" should be used to test for emptiness
* S1172: Unused function parameters should be removed
* S2699: Tests should include assertions
* S1068: Unused "private" fields should be removed
**Scala**
Include fixes to false positives and negatives for [Scala](/sonarqube-server/2026.1/analyzing-source-code/languages/scala.md) on the following rules:
* S1192: String literals should not be duplicated
* S126: "if ... else if" constructs should end with "else" clauses
**Secrets**
[Secrets](/sonarqube-server/2026.1/analyzing-source-code/languages/secrets.md) rules have been improved to reduce the detection of false positives and the following rule have been added:
* S6418: Hard-coded secrets are security-sensitive
* S2068: Hard-coded passwords are security-sensitive
* S7552: SMTP credentials should not be disclosed
* S8350: xAI API keys should not be disclosed
**VB6**
Fixes parse errors and line count for [VB6](/sonarqube-server/2026.1/analyzing-source-code/languages/vb6.md). Related rules:
* S138: Subs and functions should not have too many lines
* S1151: "Case" clauses should not have too many lines
## Update notes
This section contains notes about breaking changes and important updates to be aware of before updating. If you’re updating from the previous LTA, see [2026.1 LTA to LTA release notes](https://docs.sonarsource.com/sonarqube-server/2025.4/server-update-and-maintenance/lta-to-lta-release-notes)
2026.4
### SonarQube Server 2026.4 includes Elasticsearch 9.x
SonarQube Server 2026.4 and later includes Elasticsearch 9 (9.4.3), which requires read and write access to the `/tmp` directory. This is a requirement from Elasticsearch itself and cannot be disabled. For more information and a solution, see [On Linux systems](/sonarqube-server/2026.1/server-installation/pre-installation/linux.md#fonts).
Upgrading to Elasticsearch 9 triggers a full re-index. Because Lucene 10 cannot read the previous on-disk format, the index is rebuilt from scratch into a fresh `es9` subdirectory. Your configured index location is preserved, but its contents are regenerated.
2026.3
### Update to Microsoft SQL JDBC Auth 13.4.0
To use integrated security in a Microsoft SQL database, upgrade to the Microsoft SQL JDBC Auth 13.4.0 package. See [Installing database](/sonarqube-server/server-installation/installing-the-database.md) for more information.
2026.2
None in this release.
2026.1
### Java requirements for SonarQube Server runtime
* The SonarQube Server runtime now requires Java Development Kit (JDK). The previous requirement of a Java Runtime Environment (JRE) is no longer sufficient, and a full JDK is required.
* Added Support for Java 25 in addition to Java 21.
* Removed support for Java 17.
See [Server host requirements](/sonarqube-server/2026.1/server-installation/server-host-requirements.md#software-requirements) for more details.
### PostgreSQL support
Support for PostgreSQL versions 14 through 18 is now available, enabling deployments using the most recent PostgreSQL release. PostgreSQL version 13 is not supported anymore. See [Installing database](/sonarqube-server/2026.1/server-installation/installing-the-database.md) for more information.
### Kubernetes and Openshift support
* Supported Kubernetes Versions: From 1.32 to 1.35. Support for versions 1.30 and 1.31 has been removed.
* Supported Openshift Versions: From 4.17 to 4.20. Support for versions 4.11 to 4.16 has been removed.
### Support for MSSQL server
Supported MSSQL server is now 2022 (MSSQL Server 16.0); 2019 (MSSQL Server 15.0); 2017 (MSSQL Server 14.0). Support for 2016 MSSQL Server 13.0 support has been removed. See [Installing database](/sonarqube-server/2026.1/server-installation/installing-the-database.md) for more information.
### SonarQube Server includes Elasticsearch 8.x
SonarQube Server 2026.1 LTA and later includes Elasticsearch 8.x, which requires read and write access to the `/tmp` directory. This is a requirement from Elasticsearch itself and cannot be disabled. For more information and a solution, see [On Linux systems](/sonarqube-server/2026.1/server-installation/pre-installation/linux.md#fonts).
## Deprecations and removals
This section contains information on the deprecation and removal of SonarQube Server features and API endpoints. See the [Deprecation policy](/sonarqube-server/2026.4/server-update-and-maintenance/maintenance/deprecations/deprecation-policy.md) for more information.
2026.4
### Deprecation of Security Hotspots
To simplify the classification of findings, security hotspots are deprecated. Rules that previously raised security hotspots now raise vulnerabilities (in Standard Experience) or security issues (in MQR Mode) instead. Existing security hotspots remain visible on the Security Hotspots page.
### Java 17 support for SonarScanners has been removed
Support for Java 17 in SonarScanners has been removed in SonarQube Server 2026.4. Starting with version 2026.4, Java 21 is required. If you use JRE auto-provisioning (enabled by default on supported scanners), no action is required as Java requirements are managed automatically. However, if auto-provisioning is disabled or unsupported, you must upgrade to Java 21 or newer. For more information, see [General requirements](/sonarqube-server/2026.4/analyzing-source-code/scanners/scanner-environment/general-requirements.md).
2026.3
None in this release.
2026.2
None in this release.
2026.1
### Java 17 not supported any more
Java version 21 is the minimum version required to run SonarQube Server. See [Server host requirements](/sonarqube-server/2026.1/server-installation/server-host-requirements.md#software-requirements) for more details.
### PostgreSQL in Helm charts removed
The deprecated PostgreSQL dependency in the Helm chart has been removed. If you were relying on this dependency for production, you must take the following steps to upgrade to the new chart: back up their existing database, import the data into a new database, and then update the JDBC URL within the SonarQube chart configuration. See [Installing Helm chart](/sonarqube-server/2026.1/server-installation/on-kubernetes-or-openshift/installing-helm-chart.md) for more information.
### Kubernetes and Openshift versions removed
* Support for versions 1.30 and 1.31 has been removed.
* Support for versions 4.11 to 4.16 has been removed.
### 2016 MSSQL Server 13.0 support removed
Support for 2016 MSSQL Server 13.0 support has been removed. See [Installing database](/sonarqube-server/2026.1/server-installation/installing-the-database.md) for more information.
### Deprecation of Ingress NGINX
Due to the retirement of the ingress-nginx controller in November 2025 (with best-effort support ceasing in March 2026), the dependency on this chart is now deprecated.
We advise migrating to the [Gateway API](https://gateway-api.sigs.k8s.io/guides/), which is the modern successor to Ingress. Should you need to continue using Ingress, consult the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) for a list of suitable alternative controllers. A replacement dependency will be provided in a future release.
### Deprecation of Automatic AI Code Detection
Autodetect AI-Generated Code has been deprecated. Sonar will adjust the AI Code Assurance offering to adapt to the industry changes with high AI adoption. A warning callout has been added to the SonarQube UI in global and project settings. See [AI Code Assurance](/sonarqube-server/2026.1/ai-capabilities/ai-code-assurance.md) for more information.
## Full release notes
Links to the full release notes in Jira:
* [2026.4](https://sonarsource.atlassian.net/issues?jql=project%20%3D%2010139%20AND%20issuetype%20%21%3D%20Maintenance%20AND%20fixversion%20%3D%2033468)
* [2026.3.1](https://sonarsource.atlassian.net/issues?jql=project%20%3D%2010139%20AND%20issuetype%20!%3D%20Maintenance%20AND%20fixversion%20%3D%2035024)
* [2026.3](https://sonarsource.atlassian.net/issues?jql=project%20%3D%2010139%20AND%20issuetype%20%21%3D%20Maintenance%20AND%20fixversion%20%3D%2027751)
* [2026.2.1](https://sonarsource.atlassian.net/issues?jql=project%20%3D%2010139%20AND%20issuetype%20!%3D%20Maintenance%20AND%20fixversion%20%3D%2032454)
* [2026.2](https://sonarsource.atlassian.net/issues?jql=project%20%3D%2010139%20AND%20issuetype%20!%3D%20Maintenance%20AND%20fixversion%20%3D%2026232)
* [2026.1.3](https://sonarsource.atlassian.net/issues?jql=project%20%3D%2010139%20AND%20issuetype%20!%3D%20Maintenance%20AND%20fixversion%20%3D%2032626)
* [2026.1.2](https://sonarsource.atlassian.net/issues?jql=project%20%3D%2010139%20AND%20issuetype%20!%3D%20Maintenance%20AND%20fixversion%20%3D%2032456)
* [2026.1.1](https://sonarsource.atlassian.net/issues?jql=project%20%3D%2010139%20AND%20issuetype%20!%3D%20Maintenance%20AND%20fixversion%20%3D%2029573)
* [2026.1](https://sonarsource.atlassian.net/issues?jql=project%20%3D%2010139%20AND%20issuetype%20!%3D%20Maintenance%20AND%20fixversion%20%3D%2023523)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.sonarsource.com/sonarqube-server/2026.4/server-update-and-maintenance/release-notes.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.