Ali Najeh Tawash
opened 11 hours ago
-
Thanks for the careful scope and for separating package evidence from applicability. I checked the Community runtime wiring and the current 16.6.3 release as of 2026-09-12.
Applicability is as follows:
- CVE-2026-2332 / Jetty HTTP request smuggling: applicable. OneDev uses the embedded Jetty HTTP server, so requests reach the affected HTTP/1.1 parser. Disabling CI, Docker access, LDAP, and SSO does not remove this path. Jetty 9.4.57 is below the upstream patched 9.4.60 release. There is currently no OneDev Community release containing that fix and upstream lists no complete workaround. A reverse proxy that rejects malformed chunked requests, with direct access to OneDev blocked, is useful defense in depth but is not equivalent to updating Jetty.
- CVE-2026-10050 / Jetty Digest client authentication: not applicable to OneDev authentication.
jetty-clientis present transitively via Jetty WebSocket support, but OneDev does not instantiate JettyHttpClientorDigestAuthentication. OneDev HTTP authentication is implemented through Shiro filters instead. - GHSA-r7wm-3cxj-wff9 / Jackson async parser in Hazelcast: not reachable through the examined OneDev paths. Hazelcast 5.3.8 contains the shaded Jackson classes, but OneDev uses Hazelcast for Java-object maps, caches, coordination, and sessions, not
HazelcastJsonValue. The Hazelcast JSON paths use blocking parsers. The advisory is specific to incrementally fed non-blocking parsers, and OneDev does not use those APIs for inbound JSON. - CVE-2026-0603 / Hibernate
InlineIdsOrClauseBuilder: the injection condition is not present. All OneDev persistent entities use generatedLongidentifiers. An untrusted non-alphanumeric string therefore cannot become the entity identifier interpolated by this Hibernate bulk-operation path. - CVE-2026-49268 / Shiro
DefaultLdapRealm: not applicable. OneDev authentication does not use ShiroDefaultLdapRealm; the stated configuration also has LDAP authentication disabled. - CVE-2026-56130 / Shiro RememberMe: applicable when RememberMe is used. OneDev installs
CookieRememberMeManager, accepts RememberMe identities, and exposes the login checkbox. Shiro 1.13 does not enforce cookie age on the server. Avoiding the checkbox prevents new issuance but does not constitute complete disablement of acceptance, and OneDev currently has no supported configuration switch that completely disables this facility. Existing RememberMe cookies should be treated as valid until invalidated; restricting exposure and requiring fresh login are only interim mitigations. - CVE-2026-56091 / Shiro Guice web integration: not applicable to the examined OneDev wiring. The
shiro-guiceartifact is present, but OneDev only installs its AOP module. It does not useShiroWebModule,GuiceShiroFilter, or the Guice filter-chain provider containing the affected trailing-slash matching behavior; OneDev installs the ordinaryShiroFilterwith its own resolver.
So there is not currently a supported Community release that remediates both applicable findings. Versions 16.6.1, 16.6.2, and 16.6.3 retain Jetty 9.4.57 and Shiro 1.13.0. Replacing individual JARs is not supported: Jetty and especially Shiro 3 involve compatibility and servlet-namespace changes that need to be integrated and tested as a OneDev release.
For an immutable current-release reference only, not as a security-cleared replacement: OneDev 16.6.3 is tag/source revision
c3cc260417f02a330d59d25ae2990bd4bcd2d938; the Linux ARM64 image manifest is1dev/server@sha256:1c302c5002915610bd90b181be9f9d762f3a9ac8bf075f6a610fb3cfdb87a77f. The OCI image publishes SLSA provenance but no SBOM. The distribution includeslicense.txtand3rdparty-licenses. Java 17 or later is supported. Agents are distributed by the server and are updated to the server-bundled agent version on connection; TOD supports OneDev 15.1 and later rather than requiring an exact server release match.For native utilities and Ubuntu packages, remediation is through a newly built official OneDev image containing fixed distribution packages/utilities. In-place replacement of bundled tools or JARs is not a supported compatibility path. Please report those findings with the exact package, installed version, advisory, and image digest so each can be checked against the image build and Ubuntu status.
No code branch or PR was created for this question. If this resolves the applicability and support question, please confirm and we can close the issue.
| Type |
Question
|
| Priority |
Normal
|
| Assignee | |
| Labels |
No labels
|
Hello, could you advise on supported OneDev Community releases or configurations for the following dependency findings on Linux ARM64?
The assessed image is OneDev 16.6.1, ARM64 manifest
sha256:07b6787fc6c42c1815e4d42e2d5995835cd2eadd7b16c58b5d9ce601efd9d734. These are scanner-reported dependency findings or observations from packaged classes/public source. Their applicability to OneDev remains under investigation; this is not a claim that every advisory affects the application.The intended configuration is a private, server-only Community installation, with server CI execution disabled, no Docker socket/API, and no planned LDAP/SSO or paid features. These conditions alone do not establish non-applicability.
The first five rows originate from scanner reports checked against package evidence. The last two are additional checks against published Apache advisories and observed integration; they are not represented as scanner-confirmed application vulnerabilities.
We also assessed 16.6.2 through registry metadata and public source only. Its source still declares Jetty 9.4.57, Shiro 1.13.0 and Hibernate 5.4.24.Final. Its image has not been scanned or cleared, and unchanged version strings alone do not rule out publisher backports.
Which supported Community release, backport or documented configuration addresses these findings or establishes non-applicability? For a proposed artifact, please identify the release/source revision, immutable ARM64 digest, SBOM/licence notices, and supported Java/servlet and server-agent/TOD pairing. Guidance on supported remediation for bundled native utilities and base-OS dependency findings would also help.
We are seeking a supported compatibility/applicability path, not speculative replacement of individual JARs or a blanket security clearance. This inquiry concerns already published advisories and contains no newly discovered vulnerability or exploit report. Thank you.