> 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/server-update-and-maintenance/lta-to-lta-release-notes.md).
# LTA to LTA release notes
LTA to LTA release notes cover all new features, update notes, deprecations and removals between version 2026.1 LTA and 2026.5 LTA.
## Updating from SonarQube Server 2025.1 LTA and 2025.4 LTA
You can update your SonarQube Server from 2026.1 LTA to 2026.5 LTA directly. However, if you are updating from an earlier LTA version, you need to update to each intermediate LTA version first. Refer to the following documentation for more information:
* 2025.1 [LTA to 2025.4 LTA update notes](https://docs.sonarsource.com/sonarqube-server/2025.4/server-update-and-maintenance/lta-to-lta-release-notes)
* 2025.4 [LTA to 2026.1 LTA update notes](https://docs.sonarsource.com/sonarqube-server/2026.1/server-update-and-maintenance/lta-to-lta-release-notes)
* The Update [Overview](/sonarqube-server/server-update-and-maintenance/update/roadmap.md) page for detailed procedures.
## 2026.1 LTA to 2026.5 LTA dependencies
| Dependency | 2026.1 LTA | 2026.5 LTA | Notes |
| -------------------------------------------------------- | ------------------------------------------ | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| SonarQube Server JDK support | Java 21 or Java 25 with JDK replacing JRE. | Java 21 or Java 25 JDK | See [Software requirements](/sonarqube-server/server-installation/server-host-requirements.md#software-requirements) |
| Microsoft SQL Server | 14.0 - 16.0 | 14.0 - 17.0 | See [Setup if using an MS SQL Server database](/sonarqube-server/server-installation/installing-the-database.md#ms-sql-server) |
| Microsoft SQL JDBC Auth package | 12.10.2 | 13.4.0 | Updated in 2026.3. See [Using integrated security](/sonarqube-server/server-installation/installing-the-database.md#using-integrated-security) |
| PostgreSQL | 14-18 | 15-18 | Support for PostgreSQL version 14 has been removed in 2026.5 LTA. See [Database requirements](/sonarqube-server/server-installation/installing-the-database.md#database-requirements) |
| Oracle | 23ai, 21C, 19C, XE Editions | 26ai, 21C, 19C, XE Editions | Support for Oracle 26ai has been added in 2026.5 LTA. See [Setup if using an Oracle database](/sonarqube-server/server-installation/installing-the-database.md#oracle) |
| SonarScanner JRE support (without JRE auto-provisioning) | Java 21 | Java 21 | Java 17 was deprecated in 2025.6 and removed in 2026.4. See [General requirements](/sonarqube-server/analyzing-source-code/scanners/scanner-environment/general-requirements.md) |
| Elasticsearch | Elasticsearch 8 | Elasticsearch 9 | Updating to Elasticsearch 9 triggers a full re-index. In Data Center Edition, scale the search tier to 0 before the update and restore the replica count afterwards. See [Updating a Helm chart instance](/sonarqube-server/server-update-and-maintenance/update/update.md#helm-chart-instance) |
| Ingress Nginx | deprecated | removed | Migrate to the Gateway API. See [Migrating from Ingress NGINX to Gateway API](/sonarqube-server/server-installation/on-kubernetes-or-openshift/migrating-from-ingress-nginx-to-gateway-api.md) |
| Kubernetes support | 1.32 - 1.35 | 1.34 - 1.37 | Support for versions 1.32 and 1.33 has ended. See [On Kubernetes or OpenShift](/sonarqube-server/server-installation/on-kubernetes-or-openshift.md) |
| Openshift support | 4.17 - 4.20 | 4.18 - 4.22 | Support for version 4.17 has ended. See [On Kubernetes or OpenShift](/sonarqube-server/server-installation/on-kubernetes-or-openshift.md) |
| ZIP installation method | supported | deprecated | Still supported, but support will be removed in a future release. Consider installing from the Docker image or the Helm chart instead. See [From ZIP file](/sonarqube-server/server-installation/from-zip-file.md) |
| **SonarScanners** | | | SonarScanner versions at the time of each SonarQube Server LTA release. |
| SonarScanner CLI | 8.0.1 | 8.1 | For additional requirements, see [SonarScanner CLI](/sonarqube-server/analyzing-source-code/scanners/sonarscanner.md) |
| Azure DevOps extension | 8.0.1 | 8.2.4 | For additional requirements, see [Azure DevOps extension](/sonarqube-server/analyzing-source-code/scanners/sonarqube-extension-for-azure-devops.md) |
| Jenkins extension | 2.18 | 2.18 | For additional requirements, see [Jenkins extension](/sonarqube-server/analyzing-source-code/scanners/jenkins-extension-sonarqube.md) |
| SonarScanner for Maven | 5.5.0.6356 | 5.8.0.7211 | For additional requirements, see [SonarScanner for Maven](/sonarqube-server/analyzing-source-code/scanners/sonarscanner-for-maven.md) |
| SonarScanner for Gradle | 7.2.2.6593 | 7.4.0.8496 | For additional requirements, see [SonarScanner for Gradle](/sonarqube-server/analyzing-source-code/scanners/sonarscanner-for-gradle.md) |
| SonarScanner for .NET | 11.0.0.126294 | 11.2.0.135473 | For additional requirements, see [Installing the scanner](/sonarqube-server/analyzing-source-code/scanners/dotnet/installing.md) for .NET |
| SonarScanner for NPM | 4.3.0 | 5.0.0 | For additional requirements, see [Installing the scanner](/sonarqube-server/analyzing-source-code/scanners/npm/installing.md) for NPM |
| SonarScanner for Python | 1.3.0.4086 | 1.8.0.5390 | For additional requirements, see [SonarScanner for Python](/sonarqube-server/analyzing-source-code/scanners/sonarscanner-for-python.md) |
## Update notes
{% hint style="warning" %}
Installing SonarQube Server from the ZIP file is deprecated. It's still supported, but support will be removed in a future release, so consider the [Docker image](https://hub.docker.com/_/sonarqube) or the [Helm chart](https://artifacthub.io/packages/helm/sonarqube/sonarqube) instead. See the [deprecation policy](/sonarqube-server/server-update-and-maintenance/maintenance/deprecations/deprecation-policy.md) for details.
The agentic features run as containers, so they have no ZIP equivalent. You can keep SonarQube Server on the ZIP file and deploy their containers alongside it. See [Deploying AI agents](/sonarqube-server/server-installation/ai-agents.md).
{% endhint %}
This section covers breaking changes and important notes to be aware of before you update. See also [#deprecations-and-removals](#deprecations-and-removals "mention").
### Migration of existing Security Hotspots to issues (2026.5)
Security Hotspots are being phased out. Rules that previously raised hotspots now raise vulnerabilities (in Standard Experience) or security issues (in MQR Mode), and the hotspot findings already in your database must be converted to their new issue type. A system administrator can now run that conversion on demand through the internal `api/hotspots/migrate_to_issues` endpoint, either for a single project by passing its key as the `project` parameter, or for the whole instance by omitting it. Call `api/hotspots/migration_status` to see how many hotspots remain, and run the migration with `dryRun=true` first to preview the result.
Each finding is converted in place and keeps its key, rule, history, comments, location, assignee, and branch context, and is tagged `former-hotspot`. Findings whose rule has not been converted to an issue type, typically rules from custom plugins, are skipped and logged. The migration is idempotent, so it is safe to interrupt and re-run.
Support for Security Hotspots will be removed in a future release, at which point the migration runs automatically during the update. On instances with a large number of hotspots, migrate ahead of time and project by project to limit the load on your database.
For more information, see [Post-update steps](/sonarqube-server/server-update-and-maintenance/update/post-update-steps.md#migrate-hotspots).
### Issue backdating changes which issues count as new code (2026.5)
SonarQube Server now dates a new issue from the last commit on the affected line rather than from the analysis, so issues on unchanged lines count as old code. Issues already reported keep their dates, but as projects are reanalyzed, fewer issues fall into new code, and quality gate conditions on new code can flip from failing to passing. Review quality gates that were tuned against the previous behavior. For more information, see [SonarQube analysis process](/sonarqube-server/discovering/analysis-overview/process-steps.md#issue-backdating).
### Set the sandbox deferral before your first analysis (2026.5)
Sandboxed issues can now transition to Open status automatically after a number of days you configure, but the reopen date is recorded when an issue enters the sandbox. The setting defaults to `0`, so the issues that your first analysis on 2026.5 sends to the sandbox stay there until somebody triages them. To have that batch reopen on its own, set `sonar.issues.sandbox.deferral.days` to a positive value before you analyze. Changing the value later applies only to issues sandboxed after the change. For more information, see [Sandboxing of issues](/sonarqube-server/discovering/code-analysis/sandboxing-of-issues.md).
### Projects keep their quality profiles after the update (2026.5)
When you update to 2026.5, your projects keep the quality profiles they used before the update, and the default profile of each language stays the same. *Sonar way core* becomes the default only on new installations. To reduce the number of issues raised on a project, assign *Sonar way core* or *Sonar way extended* to it, or make one of them the default profile for a language.
For more information, see [Built-in quality profiles](/sonarqube-server/quality-standards-administration/managing-quality-profiles/built-in-quality-profiles.md) and [Changing default quality profile](/sonarqube-server/quality-standards-administration/managing-quality-profiles/changing-default-quality-profile.md).
### PostgreSQL 14 is no longer supported (2026.5)
SonarQube Server 2026.5 requires PostgreSQL 15 or later. Upgrade your database before updating. For more information, see [Installing database](/sonarqube-server/server-installation/installing-the-database.md).
### Node.js 20 is no longer supported for JavaScript and TypeScript analysis (2026.5)
The JavaScript and TypeScript analyzer embeds Node.js 24 and no longer supports Node.js 20. If you point the analyzer at your own Node.js installation, upgrade it to a supported version before updating.
For more information, see [JavaScript/TypeScript/CSS](/sonarqube-server/analyzing-source-code/languages/javascript-typescript-css.md).
### SonarQube Server requirements for agentic features (2026.5)
If you plan to use the agentic features, prepare your SonarQube Server installation:
* Deploy SonarQube Server from the Docker image or the Helm chart. The agentic features run as containers and have no ZIP equivalent. You can keep the server on a ZIP installation and deploy their containers alongside it, but installing from the ZIP file is deprecated, so we recommend moving the server to the same deployment model.
* Your license activation has to use the latest SonarQube Server licensing method, because the agentic subscriptions are added to the same license. The previous server ID-based license key cannot carry them. For more information, see [License management](/sonarqube-server/instance-administration/license-management.md) and [Sonar product subscriptions](/sonarqube-server/instance-administration/license-management/product-subscriptions.md).
For more information about deploying the agentic features, see [Before you start](/sonarqube-server/server-installation/ai-agents/before-you-start.md).
### Agentic features on Kubernetes require gVisor (2026.5)
The agentic capabilities run their jobs in a gVisor sandbox. The Helm charts install the required DaemonSet and RuntimeClass and run a pre-flight check, but the nodes that host agentic workloads must be able to run gVisor. Verify this before enabling those features on a Kubernetes cluster. On OpenShift, gVisor is not available: the agent runtimes are sandboxed with Kata Containers instead, which requires the OpenShift sandboxed containers operator.
For more information, see [Setting up the sandbox runtime](/sonarqube-server/server-installation/ai-agents/sandbox-runtime.md).
### The Helm chart no longer depends on ingress-nginx (2026.5)
The deprecated ingress-nginx dependency has been removed from the Helm chart. If your deployment relied on it to expose SonarQube Server, configure an alternative before updating. For more information, see [Migrating from Ingress NGINX to Gateway API](/sonarqube-server/server-installation/on-kubernetes-or-openshift/migrating-from-ingress-nginx-to-gateway-api.md) and [Installing Helm chart](/sonarqube-server/server-installation/on-kubernetes-or-openshift/installing-helm-chart.md).
### Higher default heap size for the web and Compute Engine processes (2026.5)
The default maximum heap size for the web server and Compute Engine processes has been raised, and it now depends on your edition. In Developer edition the web server default goes from 512m to 1G and the Compute Engine default goes from 512m to 1536m. In Enterprise edition and Data Center edition the web server default goes to 2G and the Compute Engine default goes to 4G. Instances that run close to their memory limit, and containers with a fixed memory allocation, need more memory than before. To keep your previous values, set `sonar.web.javaOpts` and `sonar.ce.javaOpts` explicitly. Setting one of these properties replaces its default value instead of extending it, so include every JVM flag you want to keep, or use the matching `javaAdditionalOpts` property to add flags without replacing the defaults.
For more information, see [Server host requirements](/sonarqube-server/server-installation/server-host-requirements.md#default-heap-sizes).
### The ABAP and RPG analyzers require Java 21 (2026.5)
The ABAP and RPG analyzers are built on a Java 21 baseline. If you run the scanner with JRE auto-provisioning, no action is required. Otherwise, make sure the scanner runs on Java 21 or later before analyzing ABAP or RPG code.
For more information, see [General requirements](/sonarqube-server/analyzing-source-code/scanners/scanner-environment/general-requirements.md).
### Enterprise Support extends how long a version stays active (2026.5)
With Enterprise Support, a SonarQube Server version stays active for 18 months, which is 6 months longer than with Standard Support. For more information, see [Release cycle model](/sonarqube-server/server-update-and-maintenance/update/release-cycle-model.md) and the comparison table for [levels of support](https://www.sonarsource.com/support/).
### Update Center supports two LTA versions per year (2026.5)
Update Center now handles two long-term active versions released in the same year, so plugin compatibility and update paths resolve correctly when more than one LTA version is current. For more information, see [Release cycle model](/sonarqube-server/server-update-and-maintenance/update/release-cycle-model.md).
### Support for Oracle 26ai and SQL Server 2025 (2026.5)
SonarQube Server supports Oracle 26ai and Microsoft SQL Server 2025. For more information, see [Installing database](/sonarqube-server/server-installation/installing-the-database.md).
### SonarQube Server 2026.4 includes Elasticsearch 9.x (2026.4)
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/server-installation/pre-installation/linux.md#elasticsearch-filesystem).
Updating 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.
### Update to Microsoft SQL JDBC Auth 13.4.0 (2026.3)
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.
## New and enhanced features
### AI capabilities
**Remediation Agent (2026.5)**
Available in Enterprise edition and higher.
The Remediation Agent fixes issues in your code and opens a pull request with the result. Assign issues to the agent from the issues list, from a pull request summary, or from a pull request's issues list, then track each job's progress and history in SonarQube Server. A scheduler can also work through a project's backlog on its own: it selects issues with the help of an LLM, respects a configured limit on open pull requests, and can be configured per project by a project administrator. The agent assigns reviewers to the pull requests it opens on GitHub, GitLab, and Azure DevOps, shows which DevOps platform connections grant it the permissions it needs, and records in the audit logs when the agent is enabled or disabled. For more information, see [Remediation Agent](/sonarqube-server/instance-administration/ai-features/remediation-agent.md).
**Hunter Agent (2026.5)**
Available in Enterprise edition and higher.
The Hunter Agent runs a deep analysis of your projects to find security flaws that static analysis alone cannot see, such as broken access control and business-logic errors. Its findings appear on the issues page, carry the usual severity and status, and can be triaged, commented on, and assigned in the same way as any other issue. Status changes and comments on those issues are published as events, and the audit logs record when Hunter Agent analysis is enabled or disabled. Findings raised by the Hunter Agent can also be handed to the Remediation Agent. For more information, see [Hunter Agent](/sonarqube-server/instance-administration/ai-features/hunter-agent.md).
**Sonar Vortex (2026.5)**
Available in Enterprise edition and higher.
Sonar Vortex helps your coding agent generate more maintainable, reliable, and secure code faster and more efficiently. It provides enhanced code navigation and context to guide your agent toward a better, more complete solution, and near-CI-grade analysis in a few seconds to prevent your agent from introducing issues in the code.
Deploy Sonar Vortex in your own agents (for example, Claude, Cursor, or Codex) through an agent plugin, the SonarQube CLI, or the SonarQube MCP Server. This requires the Sonar Vortex license. See [What is Sonar Vortex?](/agent-centric-development-cycle/inside-your-agent-the-agentic-loop/sonar-vortex.md).
Also deploy the Vortex analysis component when you use the Remediation Agent, which relies on it to verify its fixes. See [Installation overview](/sonarqube-server/server-installation/ai-agents/installation-overview.md).
**Bring your own LLM provider (2026.5)**
To use the Remediation Agent and the Hunter Agent, you need to register an LLM provider. Azure AI Foundry, AWS Bedrock, and a custom type for a model service, AI gateway, or proxy you run yourself are supported, and you can register up to 15 providers on an instance. SonarQube Server validates both the connection and the selected model when you save a provider, stores credentials encrypted, and masks them when they are read back. Every provider type other than AWS Bedrock needs an endpoint that exposes an OpenAI-compatible API. For more information, see [LLM providers](/sonarqube-server/instance-administration/ai-features/llm-providers.md).
**AI capabilities administration page (2026.5)**
A new AI capabilities page gathers the AI features of SonarQube Server in one place, so you can enable or disable each capability, choose the provider and model it uses, and open the terms and conditions that apply to it. The Remediation Agent settings that previously lived in the general settings have moved to this page. For more information, see [Overview](/sonarqube-server/instance-administration/ai-features/overview.md).
**Agentic capabilities run as containers you deploy (2026.5)**
Available in Enterprise edition and higher.
Remediation Agent, Hunter Agent, and Sonar Vortex do not run inside SonarQube Server. They run as containers you deploy alongside it, together with their supporting components: the Agent Orchestrator coordinates every job, sandboxed runtime containers run the jobs and scale with the queue, all runtime traffic leaves through an egress proxy, and you provision the shared storage that carries source snapshots and results between them. There is no ZIP equivalent for these components. For more information, see [Deploying AI agents](/sonarqube-server/server-installation/ai-agents.md) and [Agentic features architecture](/sonarqube-server/server-installation/reference-architectures/agentic-features-architecture.md).
***Sonar way for agentic AI***** quality gate (2026.4)**
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/quality-standards-administration/ai-code-assurance/quality-gate-for-agentic-ai.md).
**Embedded Model Context Protocol (MCP) for SonarQube Server (2026.3)**
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 [SonarQube Server-hosted MCP server](https://docs.sonarsource.com/sonarqube-developer-tools/sonarqube-mcp-server/setup/sonarqube-server-hosted) page for more information.
**Sonar agentic AI quality profile (2026.3)**
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.
**AI CodeFix enhancements (2026.2)**
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.
### Analysis
**New lines of code metric (2026.5)**
A New lines of code measure (`new_ncloc`) is now reported for the new code period. It applies the Lines of code definition to new code, counting physical lines that contain at least one character which is neither a whitespace nor a tabulation nor part of a comment.
New lines of code is the size measure on project cards in the new code view, in pull request and branch summaries, and in the Size domain of the Measures page, and it sizes and sorts new code treemaps. Values appear as projects are analyzed.
See the [Understanding measures and metrics](/sonarqube-server/user-guide/code-metrics/metrics-definition.md#size) article on the Understanding measures and metrics page.
**Test and coverage report imports for Scala and Ruby (2026.5)**
SonarQube Server imports ScalaTest test execution reports and Scalafix findings for Scala projects, and SimpleCov JSON coverage reports for Ruby projects.
For more information, see [Scala](/sonarqube-server/analyzing-source-code/languages/scala.md) and [Ruby](/sonarqube-server/analyzing-source-code/languages/ruby.md).
**Organization-wide architecture analysis (beta) (2026.5)**
Available in Enterprise edition and Data Center edition.
Visualize relationships between projects and enforce architecture patterns across your organization. This extends architecture analysis beyond a single project to cross-project relationships at the organization level. You can customize cross-project detection to recognize your internal libraries, in addition to the frameworks and libraries that SonarQube Server detects. Instance administrators can enable it in the global settings.
For more information, see [Enterprise architecture](/sonarqube-server/architecture-analysis/enterprise-architecture.md).
**Consistent new code fallback for reference branch analysis (2026.4)**
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/project-administration/adjusting-analysis/configuring-new-code-calculation.md).
**Faster pull request analysis for large Java and C# projects (2026.4)**
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 will not notice a difference, but on the slowest-scanning projects, pull request analysis is considerably faster.
**Software architecture analysis (2026.4)**
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.
### Issues
**Issue backdating now applied to all new issues (2026.5)**
SonarQube Server now uses the last commit date of the affected line, not the analysis date, as the issue date for every new issue, whenever SCM data is available. Issues on unchanged lines are therefore classified as old code, even when a newly activated rule, an analyzer update, or a change in compilation context such as dependencies, framework, or environment triggered them. Issues already reported in your projects keep their existing dates. New code therefore stays a reliable signal of what you changed, so your quality gate is not failed by findings on code you did not touch. For more information, see [SonarQube analysis process](/sonarqube-server/discovering/analysis-overview/process-steps.md#issue-backdating).
**Automatic transition of sandboxed issues to Open status (2026.5)**
You can now configure a number of days after which SonarQube Server automatically transitions a sandboxed issue to Open status if nobody has triaged it. Instead of remaining invisible to your quality gate indefinitely, sandboxed issues move into your regular issue counts and quality gate evaluation on their own after a grace period you control, which can turn a passing quality gate into a failing one. The setting defaults to `0`, meaning no automatic transition, so existing instances are unaffected until an instance admin turns it on. The reopen date is recorded when an issue enters the sandbox, so set `sonar.issues.sandbox.deferral.days` to a positive value before your first analysis on 2026.5 if you want the issues that the update itself sandboxes to reopen automatically. Project administrators can override it wherever they are allowed to change the Sandbox conditions. For more information, see [Sandboxing of issues](/sonarqube-server/discovering/code-analysis/sandboxing-of-issues.md).
**Issue sorting by priority (2026.5)**
The issues page can now sort issues by **Priority**, so you can focus on the most impactful issues first. Priority combines the severity of an issue with its software quality, in the order Security, Reliability, and Maintainability. It is the new default sort order, and you can also sort issues by file name or creation date.
For more information, see [Retrieving issues](/sonarqube-server/user-guide/issues/retrieving.md).
**External issue import with overlapping start and end locations (2026.4)**
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/analyzing-source-code/importing-external-issues/generic-issue-import-format.md).
**In-code issue resolution (2026.2)**
New in-code annotations (`sonar-resolve`) 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/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.
### Policies
**Three built-in Sonar way quality profiles (2026.5)**
SonarQube Server now provides three built-in quality profiles for each language, so you can choose how strict your analysis is. *Sonar way core* activates all security rules and the most impactful reliability and maintainability rules. *Sonar way extended* adds more reliability and maintainability rules. *Sonar way comprehensive* activates all recommended rules. On new installations, *Sonar way core* is the default profile for each language.
For more information, see [Built-in quality profiles](/sonarqube-server/quality-standards-administration/managing-quality-profiles/built-in-quality-profiles.md).
**Quality gate history (2026.4)**
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/quality-standards-administration/managing-quality-gates/quality-gate-history.md).
**Severity-based quality gate conditions for new code (2026.4)**
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/quality-standards-administration/managing-quality-gates/managing-custom-quality-gates.md).
**New MISRA C compliance quality profiles (2026.4)**
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/quality-standards-administration/managing-quality-profiles/understanding-quality-profiles.md) for more information.
### Security
**Masking detected secret values in source code (2026.5)**
SonarQube Server can hide the value of a detected secret instead of showing it in plain text. The **Mask detected secret values in source code** setting (`sonar.security.secretSourceRedaction.enabled`) is disabled by default. Enable it to mask secret values in the source code view and in web API responses that return source code, and where a safe location cannot be determined within a file, the whole source of that file is masked instead. The findings themselves stay visible, keeping their locations and descriptions. The setting takes effect immediately, with no reanalysis or restart. To turn it on, go to **Administration** > **Configuration** > **General Settings** > **Security**.
For more information, see [Masking detected secrets in source code](/sonarqube-server/instance-administration/security/masking-detected-secrets.md).
### Reporting
**Portfolio and project dashboards (2026.5)**
Available in Enterprise edition and higher.
Customizable dashboards are now available for portfolios and projects. Built-in dashboards cover portfolio health, project health, and a security overview, and you can assemble your own from widgets such as counts, ratings, top lists, line charts, and pie and donut charts. Widgets drill down to the findings behind each number, follow the instance's active mode (Standard experience or MQR), and can be filtered by sub-portfolio or application. An instance administrator sets how long dashboard history is kept. For more information, see [Creating dashboards](/sonarqube-server/user-guide/portfolio-dashboards/creating-dashboards.md) and [Creating dashboards](/sonarqube-server/user-guide/project-dashboards/creating-dashboards.md).
**MISRA and accessibility compliance reports (2026.5)**
Available in Enterprise edition and higher.
Compliance reports for MISRA and for WCAG accessibility are available in SonarQube Server. Each report has its own page in the project sidebar and can be filtered by finding type and by compliance level. Selecting an entry in a report opens the matching findings on the issues page, where a compliance category facet is also available. For more information, see [Regulatory reports](/sonarqube-server/user-guide/viewing-reports/regulatory-reports.md).
**EU Cyber Resilience Act report improvements (2026.5)**
Available in Enterprise edition and higher.
The EU Cyber Resilience Act report now covers dependency risks alongside code findings, breaks its results down by requirement, and can be exported as a PDF. For more information, see [Cyber Resilience Act](https://docs.sonarsource.com/cyber-resilience-act).
**EU Cyber Resilience Act security report (2026.4)**
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).
### DevOps integration
**Project coverage (2026.5)**
Project coverage shows whether every repository in your organization is connected, imported, and actually being scanned. Close any gaps by working through three steps: connect a DevOps platform, import your repositories, and get your projects analyzed. Go to **Administration** > **Project coverage** to see a progress chart for each step, a coverage timeline tracking projects analyzed and repositories imported over time, and a full project list you can search, filter, and act on individually. Viewing the page requires the Administer System permission. For more information, see [Project coverage](/sonarqube-server/quickstart-guide/project-coverage.md).
**Automated GitHub App creation (2026.4)**
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/instance-administration/devops-platforms/github/setting-up-github-app.md).
**GitLab authentication and provisioning improvements (2026.3)**
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.
### SonarQube Server operations
**System settings restricted to sonar.properties (2026.5)**
Settings that configure the server process itself are accepted only from `sonar.properties`. Setting them through the UI or the web API no longer has an effect, which removes a class of configuration that appeared to be applied but was not.
For more information, see [List of properties common to all editions](/sonarqube-server/server-installation/system-properties/common-properties.md) and [Configuration methods](/sonarqube-server/server-installation/system-properties/configuration-methods.md).
**Search stays available after an out-of-memory condition (2026.5)**
The Elasticsearch HTTP client now recovers from out-of-memory conditions instead of leaving the search component unusable until the instance is restarted.
For more information, see [SonarQube Server instance](/sonarqube-server/server-update-and-maintenance/monitoring/instance.md).
**CSRF token delivered as a response header (2026.5)**
The CSRF token is now exposed in an `X-XSRF-TOKEN` response header and read from that header, instead of being placed in a cookie that page scripts can read.
For more information, see [Web API](/sonarqube-server/extension-guide/web-api.md).
**Configurable SMTP OAuth scope (2026.5)**
The OAuth scope that SonarQube Server requests when it authenticates to an SMTP server is now configurable, which allows email notifications to work with providers that expect a scope other than the default. For more information, see [Setting up email notifications](/sonarqube-server/instance-administration/system-functions/email-notifications.md).
**Tomcat access log written to standard output (2026.5)**
The Tomcat access log is written to standard output, so containerized deployments can collect it with the rest of the SonarQube Server logs instead of reading it from a file inside the container.
For more information, see [Server logs](/sonarqube-server/server-update-and-maintenance/troubleshooting/server-logs.md).
**In-product news can be turned off for the whole instance (2026.5)**
An instance administrator can disable in-product news items for every user on the instance.
**IPv6 support for DCE Docker and Helm deployments (2026.4)**
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/server-installation/data-center-edition/on-kubernetes-or-openshift/customizing-helm-chart.md).
**Monitoring alerts for SonarQube Server administrators (2026.3)**
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.
**Configurable server-side cache expiration (2026.3)**
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 by going to **Administration** > **General Settings** > **Housekeeping**.
**Improved license renewal experience (2026.3)**
Licenses issued for a specific edition remain valid for all editions below that licensed tier, so you have time to update when renewing or changing your SonarQube Server edition. See [License management](/sonarqube-server/instance-administration/license-management.md) for more information.
**License management improvements (2026.2)**
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 [License management](/sonarqube-server/instance-administration/license-management.md) for details.
### Subscriptions and billing
**Product subscriptions on the License manager page (2026.5)**
Available in Enterprise edition and Data Center edition. Remediation Agent, Sonar Vortex, and Hunter Agent also require online license activation through the Sonar License user portal.
Remediation Agent, Sonar Vortex, Hunter Agent, and Advanced Security are sold as separate product subscriptions, each tracked on the **License manager** page's **Active products** table against a base usage limit and an overage limit. Sonar Vortex meters tool calls and the Remediation Agent meters suggestions, both resetting monthly; the Hunter Agent meters scan units that reset at the end of your contract term. Advanced Security provides full, unlimited access. Administrators are notified by email at 80% and 100% of the base allowance. For more information, see [Sonar product subscriptions](/sonarqube-server/instance-administration/license-management/product-subscriptions.md).
**Overage for product subscriptions (2026.5)**
Available in Enterprise edition and Data Center edition on instances that use online license activation and send daily pings to the license server.
Activate overage to keep a product running once its base allowance is consumed, using your existing license with no new license key required. Overage requires continuous connectivity to the license server and is blocked along with new analyses when that connection is lost. When the cap is reached, new analyses are blocked until you raise it, the billing period resets, or you upgrade your contract. Administrators are notified when overage begins and at 80% and 100% of the cap. Overage for Remediation Agent and Sonar Vortex resets monthly; Hunter Agent overage is scoped to the license term and invoiced monthly. Advanced Security does not support overage. For more information, see [Overage activation](/sonarqube-server/instance-administration/license-management/overage-activation.md).
**Overage for Lines of code (2026.5)**
Available in Enterprise edition and Data Center edition on instances that use online license activation and send daily pings to the license server.
Activate lines of code overage to keep analyzing a codebase that grows past the limit in your license, without waiting for a new license key. Billing is based on the highest lines of code peak recorded above your **Purchased LOC** limit during the month rather than on average or cumulative usage, and brief spikes are not smoothed or excluded; the recorded peak resets at the start of each calendar month. When the cap is reached, new analyses are blocked until you raise the cap. Administrators are notified when overage begins and at 80% and 100% of the cap. For more information, see [Overage activation](/sonarqube-server/instance-administration/license-management/overage-activation.md).
### UI and UX
**New layout and navigation for SonarQube Server (2026.2)**
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.
### Advanced Security
Available as part of SonarQube Advanced Security license for [Enterprise](https://www.sonarsource.com/plans-and-pricing/sonarqube/) edition and higher. See [Introduction](/sonarqube-server/advanced-security/introduction.md) for more information.
**Security alerts for critical findings (2026.5)**
Security alerts surface the findings that warrant immediate attention, such as publicly known exploitable vulnerabilities and malicious dependencies. In the top navigation bar, go to **More** > **Security alerts** to see the current alerts, filter them by type and status, and open an alert to see every project and branch where the risk is present. An alert stays open while the risk exists on any analyzed branch, and resolves automatically once the risk is gone or set to a state such as Safe. To have a group notified, go to **Administration** > **Security** > **Groups**, open the group's action menu, select **Manage subscriptions**, and add the subscription for a new security alert being raised. Members then receive an email when a new critical finding appears, and see a banner while one is present. This release covers Blocker dependency risks, and further alert types will follow. For more information, see [Alerting on critical security findings with Security Alerts](/sonarqube-server/user-guide/security-alerts.md).
**Dependency analysis with hosted vulnerability data (2026.5)**
Dependency analysis runs on your own instance while the vulnerability information it needs is retrieved from a Sonar-hosted service, so an instance that can reach that service gets current vulnerability data without sending your dependency manifests anywhere else for analysis. For more information, see [Analyzing projects for dependencies (SCA)](/sonarqube-server/advanced-security/analyzing-projects-for-dependencies.md).
**Reachability for dependency risks (2026.5)**
Dependency risks record whether the vulnerable part of a dependency is reachable from your own code, which helps you separate the risks that your code actually exercises from those that are never called. Reachability is available for Java, C#, and Python vulnerabilities. For more information, see [Reviewing and fixing dependency risks](/sonarqube-server/advanced-security/reviewing-and-fixing-dependency-risks.md#vulnerability-reachability).
**Dependency risk resolution history (2026.5)**
Dashboard widgets can chart how dependency risks have been resolved over time for a project, application, or portfolio, so you can see whether risks are being closed as fast as they arrive.
For more information, see [Creating dashboards](/sonarqube-server/user-guide/portfolio-dashboards/creating-dashboards.md).
**Bulk actions for dependency risks (2026.4)**
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/advanced-security/reviewing-and-fixing-dependency-risks.md).
**Vulnerability Exploitability Exchange (VEX) export (2026.3)**
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 (2026.3)**
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`.
**Dependency risks in security reports (2026.2)**
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 [Compliance reports](/sonarqube-server/user-guide/viewing-reports/compliance-reports.md) for details.
**Risk report and SBOM in regulatory reports (2026.2)**
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/user-guide/viewing-reports/regulatory-reports.md) for details.
**ASAST Configurations for the Python Top 1K (2026.2)**
We are expanding Advanced Static Application Security Testing (ASAST) support with the top 1,000 most utilized libraries in the Python ecosystem.
### Languages
{% hint style="info" %}
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.
{% endhint %}
ABAP
**ABAP analyzer moves to a Java 21 baseline (2026.5)**
The ABAP analyzer moves to a Java 21 baseline.
For more information, see [ABAP](/sonarqube-server/analyzing-source-code/languages/abap.md).
Apex
**Boolean check rule (2026.5)**
New rule:
* S1940: Boolean checks should not be inverted
For more information, see [Apex](/sonarqube-server/analyzing-source-code/languages/apex.md).
**Apex code quality rules (2026.2)**
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/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
C and C++
**Taint analysis reaches general availability (2026.5)**
Available in Developer edition and higher.
Taint analysis for C and C++ reaches general availability, and its rules are part of the Sonar way quality profiles for C and C++. Symbolic execution rules now reason across translation units, so a rule can follow the semantics of a function regardless of which source file defines it. The analyzer also extends its MISRA C:2012 coverage by mapping existing rules to further guidelines, which feeds the Sonar MISRA compliance quality profiles and the MISRA compliance report.
New rules:
* S2078: LDAP queries should not be vulnerable to injection attacks
* S6390: Thread suspensions should not be vulnerable to Denial of Service attacks
For more information, see [C/C++/Objective-C analysis overview](/sonarqube-server/analyzing-source-code/languages/c-family/overview.md).
C# and VB.NET
**C# and VB.NET rule updates (2026.4)**
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/analyzing-source-code/languages/csharp.md) and [VB.NET](/sonarqube-server/analyzing-source-code/languages/vb-dotnet.md).
**C# 14 contextual keyword rules (2026.3)**
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# (2026.3)**
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.
DataWeave
**DataWeave support (new) (2026.5)**
Available in Enterprise edition and higher.
SonarQube Server now analyzes MuleSoft DataWeave. Support covers DataWeave files and DataWeave embedded in Mule XML configuration files, syntax through DataWeave 2.12, syntax highlighting, and code metrics. SonarQube Server also detects Mule 4 applications and Mule XML configuration files, computes custom metrics for them, imports MUnit coverage reports and test counts, and imports Salesforce DX coverage reports.
Secret detection runs on your DataWeave and Mule XML files, as it does on every file SonarQube Server analyzes.
New DataWeave rules:
* S101: Type names should comply with a naming convention
* S103: Lines should not be too long
* S104: Files should not have too many lines
* S107: Functions should not have too many parameters
* S117: Local variable and function parameter names should comply with a naming convention
* S131: "match" expressions should include a default case
* S134: Control-flow expressions should not be nested too deeply
* S138: Functions should not have too many lines
* S1125: Boolean literals should not be redundant
* S1134: Track "FIXME" tags in comments
* S1135: Track "TODO" tags in comments
* S1151: case clauses in match expressions should not have too many lines
* S1192: String literals should not be duplicated
* S1479: "match" expressions should not have too many "case" clauses
* S1481: Unused local variables should be removed
* S1940: Boolean checks should not be inverted
* S3776: Cognitive Complexity of functions should not be too high
* S9119: DataWeave scripts should declare an output format explicitly
* S9120: The output format "application/dw" should not be used in production
* S9121: Functions should be tail recursive
* S9122: Shared DataWeave module functions should declare type annotations
* S9123: The "default" operator should be preferred over null-check conditionals
* S9124: Infix notation should be preferred for two-argument lambda calls
* S9125: Nested lambda parameters should be named
New Mule rules:
* S9086: Configuration files should not have too many flows or subflows
* S9090: HTTP Requestor reconnection strategy should use configurable values
* S9091: TLS store configurations should use configurable paths
* S9092: Applications should use APIKit to auto-generate the implementation interface
* S9093: Applications should have an APIKit error handler
* S9095: Encryption keys should not be logged
* S9097: Mule Credentials Vault should not use a hardcoded encryption key
* S9103: API ID in AutoDiscovery should not be hardcoded
* S9104: Database connection settings should not be hardcoded
* S9105: Mule Secure Properties should use AES-CBC algorithm
* S9108: HTTP Listener port should not be hardcoded in Domain configuration
* S9110: Trust Store should not have the insecure attribute
* S9112: HTTP Requestor should not use dynamic default headers or query parameters
* S9113: HTTP Requestor should have a configurable response timeout
For more information, see [MuleSoft](/sonarqube-server/analyzing-source-code/languages/mulesoft.md) and [Secrets](/sonarqube-server/analyzing-source-code/languages/secrets.md).
Go
**Test file analysis scoped to test rules (2026.3)**
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.
**Improved Go analyzer performance (2026.2)**
Go analyzer is now 30 times faster.
Gosu
**Gosu support (new) (2026.4)**
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/analyzing-source-code/languages/gosu.md).
Groovy
**Exception handling, concurrency, and Grails rules (2026.5)**
The Groovy analyzer adds rules covering exception handling, concurrency, and Grails controllers and taglibs.
New rules:
* S108: Nested blocks of code should not be left empty
* S9370: "RuntimeException" should not be caught directly
* S9371: "NullPointerException" should not be explicitly thrown
* S9372: Unused parameters should be removed from private methods and constructors
* S9373: "volatile" should not be used with "long" or "double" fields
* S9376: "servletContext" should not be used directly in controllers and taglibs
* S9378: Nested synchronized blocks should be avoided
For more information, see [Groovy](/sonarqube-server/analyzing-source-code/languages/groovy.md).
**Groovy and Jenkins pipeline rules (2026.3)**
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
**Groovy language support (beta) (2026.2)**
Initial support for Groovy language with 30+ code quality rules, enabling analysis of Groovy-based build files and scripts. See [Groovy](/sonarqube-server/analyzing-source-code/languages/groovy.md) for more information.
Related rules:
* S8268: Thread.sleep() should not be used in loops for busy waiting
* S8269: "wait()" calls should be inside "while" loops
* S8272: Classes with a "clone()" method should implement "Cloneable"
* S8275: Null checks should use correct logical operators
* S8285: Method names should follow camelCase naming conventions
* S8287: Test methods should contain assertions
* 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"
* S8303: Star imports should be replaced with explicit imports
* S8304: Duplicate import statements should be removed
* S8306: Control structures should use braces
* S8307: Semicolons should be omitted in Groovy
* S8308: Elvis operator should be used for null-safe operations and ternary simplification
* S8309: Use appropriate sorting methods to avoid mutation confusion
* S8311: Method names should not use reserved keywords
* S8314: Static imports should appear before regular imports
* S8315: Empty strings should not be used for type conversion
* S8320: GString expressions should not be used as map keys
* S8322: Simple "@Grab" annotations should use shorthand notation
* S8323: Property names should use camelCase
* S8326: Range methods should be used appropriately
HTML
**HTML language attribute rule (2026.4)**
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/analyzing-source-code/languages/html.md).
Infrastructure as Code
**Containerfile support and parsing fixes (2026.5)**
Docker analysis now covers Containerfiles in addition to Dockerfiles. Syntax highlighting no longer fails on certain Azure Resource Manager JSON files. File predicate handling is faster, and false positives are reduced across the analyzer.
For more information, see [Azure Resource Manager](/sonarqube-server/analyzing-source-code/languages/azure-resource-manager.md), [CloudFormation](/sonarqube-server/analyzing-source-code/languages/cloudformation.md), [Docker](/sonarqube-server/analyzing-source-code/languages/docker.md), [Kubernetes/Helm](/sonarqube-server/analyzing-source-code/languages/kubernetes.md), and [Terraform](/sonarqube-server/analyzing-source-code/languages/terraform.md).
**Infrastructure as Code rule and performance updates (2026.4)**
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 (AWS CloudFormation)
* S8847: Azure Key Vaults should enable purge protection (Azure Resource Manager)
* S8857: GCP Cloud Storage buckets should enforce uniform bucket-level access (Terraform)
**Multi-document Helm support and supply-chain rules (2026.3)**
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
Java
**Mockito, Spring, Quarkus, and floating-point rules (2026.5)**
The Java analyzer adds rules across the cycle, with a focus on Mockito and test doubles, Spring and Quarkus patterns, JPA, floating-point comparison, and date and time handling.
New rules:
* S909: "continue" should not be used in loops
* S8218: Instant APIs should only use supported temporal units
* S8975: The return value of "EntityManager.merge()" should be used
* S8983: Stateless session beans should not store mutable state in instance variables
* S8989: Methods annotated with @Transactional should set ‘rollbackFor’ or ‘noRollbackFor’ attributes
* S9015: Mock should be created automatically with @Mock if @ExtendWith(MockitoExtension.class) is used
* S9016: Mock objects should not be created inline within "thenReturn()"
* S9017: Mockito stubbing chains should be complete
* S9021: "@Configuration" classes should not be final
* S9024: @InjectMocks should be preferred over manual initialization
* S9068: "@ApplicationScoped" should be preferred over "@Singleton" in Quarkus applications
* S9130: Stream read results should be checked for -1 before casting
* S9132: "ScheduledThreadPoolExecutor.setMaximumPoolSize" should not be called
* S9133: Predefined mathematical constants should be used instead of hard-coded approximations
* S9142: Expensive compilation or preparation operations should not be performed inside loops
* S9146: Apache XML RPC extensions should not be enabled
* S9147: "NaN" should not be tested for equality using "==" or "!="
* S9148: "Float.compare" or "Double.compare" should be used for floating-point comparisons
* S9149: Static methods should not hide methods from superclasses
* S9341: Redundant Spring annotations should be removed
* S9342: Archive entries should not be empty
* S9344: Bitwise AND operations with zero should be corrected
* S9345: Classes with throwing constructors should be protected against Finalizer attacks
* S9346: Integer values should not be cast to long for use as timestamps
* S9354: "Comparable.compareTo()" and "Comparator.compare()" should not use subtraction on numerical fields
* S9357: Anonymous classes on functional interfaces should be lambdas
* S9358: Conditional expressions should not duplicate operations in both branches
* S9359: Octal escape sequences should not be followed by digits
* S9361: Duplicate keys or elements should not be passed to immutable collection factory methods
* S9362: hashCode() and equals() should use consistent fields
* S9363: Invalid time-zone IDs should not silently fall back to GMT
* S9364: Local variables should not span switch case groups
* S9365: Copy constructors should initialize all fields
Rule S2442 (Synchronizing on a "java.util.concurrent" object should be avoided) has been extended to cover more cases.
For more information, see [Java](/sonarqube-server/analyzing-source-code/languages/java.md).
**Java date, time, and framework rules (2026.4)**
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/analyzing-source-code/languages/java.md).
**Java analyzer rule and stability update (2026.3)**
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
**Java 25 support (2026.2)**
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/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/CSS
**Vue, utility library, and testing rules (2026.5)**
The JavaScript and TypeScript analyzer adds rules for Vue, for utility libraries such as Lodash, Underscore.js, jQuery, and Axios, and for testing with Testing Library, Cypress, Playwright, and Vitest. The embedded Node.js runtime moves to 24.19, and Node.js 20 is no longer supported.
New rules:
* S6544: Promises should not be misused
* S8957: Vue component props should declare a type
* S8982: HTML elements with v-for should have a :key attribute
* S8984: Vue v-for directives should be valid
* S8987: "v-if" and "v-for" should not be used on the same element
* S8988: Side effects should not be performed inside Vue computed properties
* S9011: "\Kotlin
**Kotlin 2.3.10 support (2026.2)**
Upgraded the Kotlin analyzer for version 2.3.10 support.
Package manager analyzer
**Lock file and Unicode rules (2026.3)**
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
**Rule deprecation (2026.3)**
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
PL/SQL and T-SQL
**Shared SQL configuration category (2026.4)**
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/analyzing-source-code/languages/pl-sql.md) and [T-SQL](/sonarqube-server/analyzing-source-code/languages/t-sql.md).
PostgreSQL
**PostgreSQL support (new) (2026.4)**
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/analyzing-source-code/languages/postgres.md).
PowerShell
**PowerShell support (2026.3)**
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
**pytest, unittest.mock, and Pydantic rules (2026.5)**
The Python analyzer adds a large set of rules for testing with pytest and for mocking with unittest.mock, along with further Pydantic rules.
New rules:
* S8953: Pydantic models should enable either alias or name validation
* S8978: Pydantic models with dataclass fields should set "revalidate\_instances"
* S8992: Pytest fixtures should not combine "autouse" with "params"
* S8993: Test functions should declare fixture dependencies as parameters instead of using "request.getfixturevalue"
* S8994: Pytest fixtures should contain at most one yield statement
* S8997: Tests should use the "monkeypatch" fixture for temporary modifications
* S8998: Parametrize decorators should not have empty parameter lists
* S8999: "pytest\_plugins" should be defined in conftest.py files
* S9000: "pytest.raises" should be used as a context manager
* S9001: Expected test failures should provide a reason
* S9002: Function-scoped tests should use "tmp\_path" instead of "tmp\_path\_factory"
* S9073: Composite assertions should be split
* S9074: Pytest marks and usefixtures should not be applied uselessly
* S9075: Tests should check which warning is expected
* S9076: Deprecated pytest.yield\_fixture should be replaced with pytest.fixture
* S9077: Intentional test failures should use pytest.fail with a message
* S9078: Parametrize decorators should not contain duplicate test cases
* S9080: Pytest fixtures should use yield for teardown
* S9081: Mocks should use return\_value instead of patching with a lambda that only returns a value
* S9083: Pytest fixture and mark decorators should use consistent parentheses style
* S9084: pytest should be imported as a module
* S9088: Only one method invocation is expected when testing warnings
* S9100: Pytest fixtures without teardown should use return instead of yield
* S9106: Pytest test and fixture parameters should not declare default values
* S9116: Pytest fixture options should be passed as keyword arguments
* S9117: Pytest fixtures should not declare the default scope="function"
* S9134: Pydantic field validators should return the validated value
* S9136: Mock assertion method names should be spelled correctly
* S9137: Mocks should be created with autospec
The following rules are no longer raised on Django auto-generated migration files:
* S125: Sections of code should not be commented out
* S1192: String literals should not be duplicated
* S3776: Cognitive Complexity of functions should not be too high
* S5145: Logging should not be vulnerable to injection attacks
For more information, see [Python](/sonarqube-server/analyzing-source-code/languages/python.md).
**Testing, Pydantic, and Beautiful Soup rules (2026.4)**
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/analyzing-source-code/languages/python.md).
**Python collections rules (2026.3)**
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 (2026.3)**
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 (2026.3)**
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
**Python Django framework rules (2026.2)**
New rules specifically targeting Django best practices and common pitfalls for web developers. See [Python](/sonarqube-server/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 (2026.2)**
Flask services get dedicated rules to harden configuration, routing, and error handling, focusing on security and correctness of HTTP behavior. See [Python](/sonarqube-server/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 (2026.2)**
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/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
R
**R support (new) (2026.5)**
SonarQube Server now analyzes R. Support covers parsing, syntax highlighting, and metrics, embedded R code in R Markdown, Cobertura coverage report import, and import of lintr findings as external issues, along with an initial set of code quality rules.
New rules:
* 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
* S1145: Useless "if (TRUE) { ... }" and "if (FALSE) { ... }" blocks should be removed
* S1192: String literals should not be duplicated
* S1607: Tests should not be ignored without a reason
* S1862: Related "ifelse if" statements should not have the same condition
* S1940: Boolean checks should not be inverted
* S3358: "ifelse()" calls should not be nested
* S3776: Cognitive Complexity of functions should not be too high
* S5863: Assertions should not be given twice the same argument
* S6880: Use "switch()" instead of an if-else chain for multiple value comparisons
* S9252: "all.equal()" should be wrapped in "isTRUE()" or replaced with "identical()"
* S9253: "anyDuplicated()" should be used instead of "any(duplicated())"
* S9256: Error and warning messages should suppress call information
* S9257: Consecutive assertion calls should be combined into a single call
* S9261: Unnecessary concatenation should be avoided
* S9262: Loop index variables should not shadow iterable variables
* S9266: Assignments should not be implicit within function calls or conditionals
* S9269: Size-checking functions should be applied to data structures, not to logical comparison results
* S9273: Negation should be applied after logical aggregation functions
* S9274: Logging functions should be used instead of "print()" for string output
* S9278: Format specifiers should match the provided arguments in "sprintf()" calls
* S9280: Redundant "file.path()" calls should not be used with "system.file()"
* S9281: Resources should be closed using "on.exit()" instead of terminal "close()" calls
* S9282: Super-assignment operators should not be used
* S9284: Consecutive suppressed library calls should be consolidated
* S9285: Library calls should be placed at the beginning of scripts
* S9288: File paths should be relative, not absolute
* S9289: File paths should be constructed using "file.path()"
* S9292: "return()" should not be used inside magrittr pipelines
* S9293: Single-call pipes should be avoided
* S9294: Redundant numeric type checks should be simplified
* S9297: "any(is.na())" should be replaced with "anyNA()"
* S9300: Arithmetic operations should not be used on boolean results
* S9302: Variables should not shadow common R functions
* S9305: Test assertions should check one condition at a time
* S9306: Consecutive calls to "mutate()" should be combined
* S9307: The most appropriate assertion function should be used
* S9308: Fixed string boundaries should be checked with "startsWith()" or "endsWith()"
* S9309: Test assertion arguments should be in the correct order
* S9310: "stopifnot" with unnamed arguments should not use compound conditions
* S9311: Redundant "all()" calls should be removed from "stopifnot()"
* S9314: Keyword argument names should not be quoted
* S9316: Native routines should be registered
* S9317: Calls in magrittr pipes should be explicit
* S9318: Type coercion functions should not be used on literal values
* S9319: Unnecessary anonymous functions should be simplified
* S9320: Non-exported functions should not be accessed with the ':::' operator
* S9322: "require()" should not be used in ".onAttach()" hook functions
* S9326: Unnecessary pipeline placeholders should be removed
* S9327: "grep" should be used instead of "which(grepl)"
* S9328: Error handlers should not silently return NULL
* S9329: Merge operations should specify join keys
For more information, see [R](/sonarqube-server/analyzing-source-code/languages/r.md).
RPG
**RPG analyzer moves to a Java 21 baseline (2026.5)**
The RPG analyzer moves to a Java 21 baseline and removes its deprecated APIs.
Removed rule:
* S1628: Debugging statements "DEBUG(\*YES)" and "DUMP" should not be used
For more information, see [RPG](/sonarqube-server/analyzing-source-code/languages/rpg.md).
**RPG rules and multiline issues (2026.3)**
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
**SimpleCov import and test detection (2026.5)**
The Ruby analyzer imports SimpleCov 1.0.0 JSON coverage reports and improves how it detects test code.
New rule:
* S1940: Boolean checks should not be inverted
For more information, see [Ruby](/sonarqube-server/analyzing-source-code/languages/ruby.md).
**Ruby analysis performance (2026.3)**
Ruby analysis has been improved, delivering enhanced analysis performance. See [Ruby](/sonarqube-server/analyzing-source-code/languages/ruby.md) for more information.
**Ruby rules (beta) (2026.2)**
There are eight ruby rules in beta and two that have been removed. See [Ruby](/sonarqube-server/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
Rust
**Security rules and faster Clippy rules (2026.5)**
The Rust analyzer adds 12 security rules, the first for Rust, and 37 Clippy rules that run up to 25 times faster. It also adds rules for the Tokio framework, ports a set of rules from other languages, and raises the default Cognitive Complexity threshold for Rust to 30.
Examples of rules:
* S2629: Error context arguments should not require evaluation
* S2737: Error conversions already performed by "?" should be removed
* S5850: Alternatives in regular expressions should be grouped when used with anchors
* S5868: Unicode Grapheme Clusters should be avoided inside regex character classes
* S5869: Character classes in regular expressions should not contain the same character twice
* S5917: Date format strings should not mix calendar and ISO week-based specifiers
* S6035: Single-character alternations in regular expressions should be replaced with character classes
* S6326: Regular expressions should not contain multiple spaces
* S6677: Structured logging field names should be unique
* S6882: Date and time constructor arguments should be in the range of possible values
* S7487: Async functions should not contain synchronous subprocess calls
* S7488: Use non-blocking sleep functions in asynchronous code
* S7493: Async functions should not contain synchronous file operations
* S8855: Documentation comments should not be followed by empty lines
* S8865: Comparison expressions should be simplified by removing unnecessary arithmetic
* S8877: Integer and string literals should not use confusing C-style notation
* S8885: Pattern bindings with wildcards should not be redundant
* S9061: Test attributes should not be used in doctests without markers
Modified rule:
* S3776: Cognitive Complexity of functions should not be too high
For more information, see [Rust](/sonarqube-server/analyzing-source-code/languages/rust.md).
**Clippy rule support (2026.3)**
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
Secrets
**JWK private key rule and demo mode (2026.5)**
Secret detection adds a rule for JWK private keys and a demo mode that makes it easier to show the feature on sample code. Every secrets rule now carries the `secret` tag.
New rule:
* S9131: JWK private keys should not be disclosed
Detection accuracy improves through a more precise base64 post-filter, and false positives are reduced on example and test JWTs, on identifiers and SOPS-encrypted values, and on generated lock files. The package manager dependency locking rules recognize rush.js centralized lock files and `bun.lockb`.
For more information, see [Secrets](/sonarqube-server/analyzing-source-code/languages/secrets.md).
**Secret detection improvements (2026.4)**
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/analyzing-source-code/languages/secrets.md).
XML
**MuleSoft rule updates (2026.5)**
The MuleSoft rules shipped by the XML analyzer are updated. The threshold for inline DataWeave lines of code is now configurable, and the flow naming convention rule has been removed from the Sonar way quality profiles.
Modified rules:
* S9087: Flow and subflow names should follow a naming convention
* S9089: Data transformations should be stored in external DWL files
For more information, see [XML](/sonarqube-server/analyzing-source-code/languages/xml.md).
## 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/server-update-and-maintenance/maintenance/deprecations/deprecation-policy.md) for more information.
### Installation from the ZIP file is deprecated (2026.5)
Installing SonarQube Server from the ZIP file is deprecated. It's still supported, but support will be removed in a future release, so consider the [Docker image](https://hub.docker.com/_/sonarqube) or the [Helm chart](https://artifacthub.io/packages/helm/sonarqube/sonarqube) instead, or the [Docker image](/sonarqube-server/server-installation/data-center-edition/from-docker-image.md) or the [DCE Helm chart](https://artifacthub.io/packages/helm/sonarqube/sonarqube-dce) for the Data Center edition.
The AI features run as containers, so they have no ZIP equivalent. You can keep SonarQube Server on the ZIP file and deploy their containers alongside it. For more information, see [From ZIP file](/sonarqube-server/server-installation/from-zip-file.md) and [Deploying AI agents](/sonarqube-server/server-installation/ai-agents.md).
### PostgreSQL 14 support removed (2026.5)
Support for PostgreSQL 14 has been removed. PostgreSQL 15 or later is required. For more information, see [Installing database](/sonarqube-server/server-installation/installing-the-database.md).
### Node.js 20 support removed from the JavaScript and TypeScript analyzer (2026.5)
The JavaScript and TypeScript analyzer embeds Node.js 24 and no longer supports Node.js 20.
For more information, see [JavaScript/TypeScript/CSS](/sonarqube-server/analyzing-source-code/languages/javascript-typescript-css.md).
### Ingress NGINX dependency removed from the Helm chart (2026.5)
The ingress-nginx chart dependency, deprecated in 2026.1 after the controller's retirement, has been removed. Migrate to the [Gateway API](https://gateway-api.sigs.k8s.io/guides/) or to another ingress controller. For more information, see [Migrating from Ingress NGINX to Gateway API](/sonarqube-server/server-installation/on-kubernetes-or-openshift/migrating-from-ingress-nginx-to-gateway-api.md).
### Deprecated web API endpoints for project bindings (2026.5)
The legacy `set_*_binding` endpoints and the remaining v1 endpoints for DevOps platform project bindings are deprecated. Move to the v2 project binding endpoints. For more information, see [Deprecation policy](/sonarqube-server/server-update-and-maintenance/maintenance/deprecations/deprecation-policy.md).
### Deprecated accessibility reports web API endpoint (2026.5)
The web API endpoint that returned accessibility reports is deprecated, superseded by the compliance reports endpoint that serves both the MISRA and the WCAG accessibility reports.
For more information, see [Web API](/sonarqube-server/extension-guide/web-api.md).
### Deprecation of security hotspots (2026.4)
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 (2026.4)
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/analyzing-source-code/scanners/scanner-environment/general-requirements.md).
---
# 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/server-update-and-maintenance/lta-to-lta-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.