Lancé par une alarme périodiqueSKIP_TESTfalseSKIP_QUALITYfalse57156f5661a313b8828cac18f92b68f2f116fbd2cc256f5661a313b8828cac18f92b68f2f116fbd2cc2refs/remotes/origin/master56f5661a313b8828cac18f92b68f2f116fbd2cc256f5661a313b8828cac18f92b68f2f116fbd2cc2refs/remotes/origin/master56f5661a313b8828cac18f92b68f2f116fbd2cc256f5661a313b8828cac18f92b68f2f116fbd2cc2refs/remotes/origin/masterhttps://github.com/Silverpeas/Jenkins-Pipelines.git18045e0d31d27a05fd6c36b5f7bd604a0d05f7f378f45e0d31d27a05fd6c36b5f7bd604a0d05f7f378frefs/remotes/origin/6.2.x45e0d31d27a05fd6c36b5f7bd604a0d05f7f378f45e0d31d27a05fd6c36b5f7bd604a0d05f7f378frefs/remotes/origin/6.2.x3026df43e66c82d74fdaf07c75d56db339cf34913646df43e66c82d74fdaf07c75d56db339cf3491364refs/remotes/origin/6.3.x6df43e66c82d74fdaf07c75d56db339cf34913646df43e66c82d74fdaf07c75d56db339cf3491364refs/remotes/origin/6.3.x57150d31f738f19b3d7b37a86554870383fa9d856e250d31f738f19b3d7b37a86554870383fa9d856e2refs/remotes/origin/6.4.x50d31f738f19b3d7b37a86554870383fa9d856e250d31f738f19b3d7b37a86554870383fa9d856e2refs/remotes/origin/6.4.x43a3e9b3a1a829e2b076e72afa8bf8da6253ba6b31a3e9b3a1a829e2b076e72afa8bf8da6253ba6b31refs/remotes/origin/6.1.xa3e9b3a1a829e2b076e72afa8bf8da6253ba6b31a3e9b3a1a829e2b076e72afa8bf8da6253ba6b31refs/remotes/origin/6.1.x50d31f738f19b3d7b37a86554870383fa9d856e250d31f738f19b3d7b37a86554870383fa9d856e2refs/remotes/origin/6.4.xhttps://github.com/Silverpeas/Silverpeas-Core1796976f0d418d1eb565dded101d00140960944e6aa6976f0d418d1eb565dded101d00140960944e6aarefs/remotes/origin/6.2.x6976f0d418d1eb565dded101d00140960944e6aa6976f0d418d1eb565dded101d00140960944e6aarefs/remotes/origin/6.2.x302f1c18f5b16ecf085b04a36a636aa4aa26ec5d773f1c18f5b16ecf085b04a36a636aa4aa26ec5d773refs/remotes/origin/6.3.xf1c18f5b16ecf085b04a36a636aa4aa26ec5d773f1c18f5b16ecf085b04a36a636aa4aa26ec5d773refs/remotes/origin/6.3.x571de9cf8606c9910989890a6d004cd47a8e2f611cade9cf8606c9910989890a6d004cd47a8e2f611carefs/remotes/origin/6.4.xde9cf8606c9910989890a6d004cd47a8e2f611cade9cf8606c9910989890a6d004cd47a8e2f611carefs/remotes/origin/6.4.x439dbcbf90b830646ccd42fb388d09dbe09ecea4e69dbcbf90b830646ccd42fb388d09dbe09ecea4e6refs/remotes/origin/6.1.x9dbcbf90b830646ccd42fb388d09dbe09ecea4e69dbcbf90b830646ccd42fb388d09dbe09ecea4e6refs/remotes/origin/6.1.xde9cf8606c9910989890a6d004cd47a8e2f611cade9cf8606c9910989890a6d004cd47a8e2f611carefs/remotes/origin/6.4.xhttps://github.com/Silverpeas/Silverpeas-Components179b3b8a633d5a98083849becc7464aebbca4218501b3b8a633d5a98083849becc7464aebbca4218501refs/remotes/origin/6.2.xb3b8a633d5a98083849becc7464aebbca4218501b3b8a633d5a98083849becc7464aebbca4218501refs/remotes/origin/6.2.x302586ebdd23e10f812e41a52cbf1a3a7f4a81fe924586ebdd23e10f812e41a52cbf1a3a7f4a81fe924refs/remotes/origin/6.3.x586ebdd23e10f812e41a52cbf1a3a7f4a81fe924586ebdd23e10f812e41a52cbf1a3a7f4a81fe924refs/remotes/origin/6.3.x571f105160616b668c112072a2f4714b531c52c98bcf105160616b668c112072a2f4714b531c52c98bcrefs/remotes/origin/6.4.xf105160616b668c112072a2f4714b531c52c98bcf105160616b668c112072a2f4714b531c52c98bcrefs/remotes/origin/6.4.x43070793013d99eb148b16b15d6a191b20b72bc82c070793013d99eb148b16b15d6a191b20b72bc82crefs/remotes/origin/6.1.x070793013d99eb148b16b15d6a191b20b72bc82c070793013d99eb148b16b15d6a191b20b72bc82crefs/remotes/origin/6.1.xf105160616b668c112072a2f4714b531c52c98bcf105160616b668c112072a2f4714b531c52c98bcrefs/remotes/origin/6.4.xhttps://github.com/Silverpeas/Silverpeas-Looks179abe99f69032413c083fb9ee7a98afc1e2ab5114dabe99f69032413c083fb9ee7a98afc1e2ab5114drefs/remotes/origin/6.2.xabe99f69032413c083fb9ee7a98afc1e2ab5114dabe99f69032413c083fb9ee7a98afc1e2ab5114drefs/remotes/origin/6.2.x302146430cd63566b3be410c8dd534faa57033583b3146430cd63566b3be410c8dd534faa57033583b3refs/remotes/origin/6.3.x146430cd63566b3be410c8dd534faa57033583b3146430cd63566b3be410c8dd534faa57033583b3refs/remotes/origin/6.3.x571f9a3cc8ddfdefbb340e23594a0d441da1d2cd613f9a3cc8ddfdefbb340e23594a0d441da1d2cd613refs/remotes/origin/6.4.xf9a3cc8ddfdefbb340e23594a0d441da1d2cd613f9a3cc8ddfdefbb340e23594a0d441da1d2cd613refs/remotes/origin/6.4.x4362ef5e63f545c1d332fb8e528897aff1fac5415062ef5e63f545c1d332fb8e528897aff1fac54150refs/remotes/origin/6.1.x62ef5e63f545c1d332fb8e528897aff1fac5415062ef5e63f545c1d332fb8e528897aff1fac54150refs/remotes/origin/6.1.xf9a3cc8ddfdefbb340e23594a0d441da1d2cd613f9a3cc8ddfdefbb340e23594a0d441da1d2cd613refs/remotes/origin/6.4.xhttps://github.com/Silverpeas/Silverpeas-Setup179c96d415a32db2f558555695b382b89c11ac347bec96d415a32db2f558555695b382b89c11ac347berefs/remotes/origin/6.2.xc96d415a32db2f558555695b382b89c11ac347bec96d415a32db2f558555695b382b89c11ac347berefs/remotes/origin/6.2.x30210719018413e414cfa70c0f64a945a72670797f410719018413e414cfa70c0f64a945a72670797f4refs/remotes/origin/6.3.x10719018413e414cfa70c0f64a945a72670797f410719018413e414cfa70c0f64a945a72670797f4refs/remotes/origin/6.3.x5714c911d0c826d86eae553a296dd6f65961fc161ae4c911d0c826d86eae553a296dd6f65961fc161aerefs/remotes/origin/6.4.x4c911d0c826d86eae553a296dd6f65961fc161ae4c911d0c826d86eae553a296dd6f65961fc161aerefs/remotes/origin/6.4.x432c1de09b276e4aa8622563451ebd70a4f24759ce2c1de09b276e4aa8622563451ebd70a4f24759cerefs/remotes/origin/6.1.x2c1de09b276e4aa8622563451ebd70a4f24759ce2c1de09b276e4aa8622563451ebd70a4f24759cerefs/remotes/origin/6.1.x4c911d0c826d86eae553a296dd6f65961fc161ae4c911d0c826d86eae553a296dd6f65961fc161aerefs/remotes/origin/6.4.xhttps://github.com/Silverpeas/Silverpeas-Distribution1791bdb8f99972aa96dacfc6d8775a7364ab6e845c21bdb8f99972aa96dacfc6d8775a7364ab6e845c2refs/remotes/origin/6.2.x1bdb8f99972aa96dacfc6d8775a7364ab6e845c21bdb8f99972aa96dacfc6d8775a7364ab6e845c2refs/remotes/origin/6.2.x302e6cf90efb933ea1d65558af1cade3056ac4b6462e6cf90efb933ea1d65558af1cade3056ac4b6462refs/remotes/origin/6.3.xe6cf90efb933ea1d65558af1cade3056ac4b6462e6cf90efb933ea1d65558af1cade3056ac4b6462refs/remotes/origin/6.3.x57127fc17db8fc8e443cd002cec7d78fbad61804ec827fc17db8fc8e443cd002cec7d78fbad61804ec8refs/remotes/origin/6.4.x27fc17db8fc8e443cd002cec7d78fbad61804ec827fc17db8fc8e443cd002cec7d78fbad61804ec8refs/remotes/origin/6.4.x4364a1ed5c344bf6e81820366b63120c460193579c64a1ed5c344bf6e81820366b63120c460193579crefs/remotes/origin/6.1.x64a1ed5c344bf6e81820366b63120c460193579c64a1ed5c344bf6e81820366b63120c460193579crefs/remotes/origin/6.1.x27fc17db8fc8e443cd002cec7d78fbad61804ec827fc17db8fc8e443cd002cec7d78fbad61804ec8refs/remotes/origin/6.4.xhttps://github.com/Silverpeas/Silverpeas-AssemblyAaD2JBITnW7s-NNcLCz7Silverpeas SonarCloudhttps://sonarcloud.iotruehttps://sonarcloud.iofalsehttps://sonarcloud.io/dashboard?id=Silverpeas_Silverpeas-Core2&branch=6.4.xAaD2RaVYkj6CGoBn8DnaSilverpeas SonarCloudhttps://sonarcloud.iotruehttps://sonarcloud.iofalsehttps://sonarcloud.io/dashboard?id=Silverpeas_Silverpeas-Components&branch=6.4.xbuild.yamlbuild.yamltarget/build.yamlfalse6.4.8-build26100191182245497799Silverpeas_Stable_AutoDeploy 6.4.8-build261001571false57164011SUCCESS1790829960596https://integration.silverpeas.org/jenkins/job/Silverpeas_Stable_AutoDeploy/571/core-web/src/main/java/org/silverpeas/core/web/filter/MassiveWebSecurityFilter.javacore-web-test/src/main/java/org/silverpeas/web/test/stub/TestHttpRequest.javacore-web/src/integration-test/java/org/silverpeas/core/web/filter/MassiveWebSecurityFilterOnReportedXssIT.javacbca010a1bf431ccce251585dcf892700d9f42721790599035000https://integration.silverpeas.org/jenkins/user/mmoquillonMiguel Moquillonmiguel.moquillon@gmail.comHarden the detection of the event callbacks against the vulnerabilities #1458, #1459 and #1460 (GitHub issues, reported against 6.4.6) The three reported stored XSS rely on an event callback attribute carried by an element the browser fails to load on purpose. Such a declaration was detected by the \s+on\w+\s*= pattern, which expects a whitespace before the attribute name. According to the HTML tokenizer, an attribute name is also expected right after the closing quote of the previous attribute value (a missing-whitespace-between-attributes parse error, whose recovery is mandated by the specification) and right after a solidus. So the following did declare an onerror callback the browsers do run, while going through the filter: <img src="x"onerror=alert(1)> The pattern now accepts these separators as well. Note this filter is an input guard, not an output encoding: it narrows the reachability of the three flaws but it doesn't fix the rendering code itself. MassiveWebSecurityFilterOnReportedXssIT covers the payloads of the three reports on their actual endpoints and parameters, including when they are submitted as multipart/form-data streams as the genuine forms do. It also delimits the multipart exemption, which applies to the webPages component only. TestHttpRequest.getContentType() returned null whatever the headers set on the stub, which made the multipart branch untestable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> 2026-09-28 14:37:15 +0200cbca010a1bf431ccce251585dcf892700d9f4272Harden the detection of the event callbacks against the vulnerabilities #1458, #1459 and #1460editcore-web-test/src/main/java/org/silverpeas/web/test/stub/TestHttpRequest.javaaddcore-web/src/integration-test/java/org/silverpeas/core/web/filter/MassiveWebSecurityFilterOnReportedXssIT.javaeditcore-web/src/main/java/org/silverpeas/core/web/filter/MassiveWebSecurityFilter.javacore-war/src/main/webapp/defaultLoginQuestion.jspb8e6d6bb35fda9a02280c287662a61e7683c275a1790599035000https://integration.silverpeas.org/jenkins/user/mmoquillonMiguel Moquillonmiguel.moquillon@gmail.comFix vulnerability #1458 (GitHub issue, reported against 6.4.6) The login question, which any authenticated user sets from their profile, was printed raw by a JSP scriptlet on the password reminder page, an anonymous one. Any script stored there was then run in the browser of every visitor of that page, without any login required from them. The answer to that question, itself a credential, is asked on the very same page. The value is now HTML encoded on output, through a c:out tag. Doing so on the rendering side rather than on the writing one closes both the ways the field is fed: MyProfilRequestRouter, which the report points at, but also ValidationQuestionHandler, which stores the question of the ValidateQuestion function with no more filtering. It also neutralizes the values already stored. The login of the hidden field below is encoded as well. It comes from a lookup in the database and not from the request parameter, so exploiting it would require a login holding a quote, but the encoding costs nothing here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> 2026-09-28 14:37:15 +0200b8e6d6bb35fda9a02280c287662a61e7683c275aFix vulnerability #1458editcore-war/src/main/webapp/defaultLoginQuestion.jspcore-web/src/main/java/org/silverpeas/core/web/filter/IFrameChecker.javacore-library/src/main/java/org/silverpeas/core/contribution/content/wysiwyg/service/directive/SanitizeForRenderingDirective.javacore-services/importExport/src/main/java/org/silverpeas/core/importexport/report/HtmlExportPublicationGenerator.javacore-configuration/src/main/config/properties/org/silverpeas/util/security.propertiescore-library/src/main/java/org/silverpeas/core/contribution/content/form/displayers/WysiwygFCKFieldDisplayer.javacore-library/src/integration-test/java/org/silverpeas/core/test/WarBuilder4LibCore.javacore-library/src/integration-test/resources/org/silverpeas/util/security.propertiescore-library/src/main/java/org/silverpeas/core/contribution/content/wysiwyg/service/WysiwygContentRenderer.javacore-api/src/main/java/org/silverpeas/core/security/html/EmbeddedSourceValidator.javacore-library/src/integration-test/java/org/silverpeas/core/contribution/content/wysiwyg/service/WysiwygControllerIT.javacore-library/src/test/java/org/silverpeas/core/contribution/content/wysiwyg/service/WysiwygContentTransformerTest.javacore-api/src/main/java/org/silverpeas/core/util/security/SecuritySettings.javacore-services/importExport/src/main/java/org/silverpeas/core/importexport/control/PublicationsTypeManager.javacore-library/src/main/java/org/silverpeas/core/contribution/content/wysiwyg/service/WysiwygContentTransformer.java661dad84ee2e8251e0a0291c75876b2f91db5aef1790599035000https://integration.silverpeas.org/jenkins/user/mmoquillonMiguel Moquillonmiguel.moquillon@gmail.comFix vulnerability #1459 (GitHub issue, reported against 6.4.6) The WYSIWYG content of a form field was written into the response as raw HTML by WysiwygFCKFieldDisplayer, so any script stored by the writer of a whitePages card was run in the browser of every user viewing it. The same held for the content of a publication, rendered by WysiwygContentRenderer, and for the two export paths, none of which was reported. Such a content is sanitized now, by the new SanitizeForRenderingDirective. Unlike SanitizeDirective, which keeps only a restricted set of safe elements and is left untouched for the contents extracted out of Silverpeas, this one keeps the content as it is and drops only what can act on the visitor's browser: - the elements able to run code or to take over the document, with their content; - the event callback attributes, whatever the element carrying them; - the attributes referring a URL with a scripting scheme; - the iframes and the media whose source isn't allowed. This is deliberate: the WYSIWYG editor is set up to accept any content (config.allowedContent = true in silverconfig.js), so an allow list applied at rendering time would be narrower than what the users are entitled to write. It would in particular have dropped the media produced by the video and html5audio plugins and the rel attribute the userzoom and identitycard ones rely upon. The parsing is delegated to the HTML tokenizer of the OWASP sanitizer, so the content is read the way a browser reads it and the dropping can't be dodged by playing with the HTML syntax. The rule deciding whether the source of an iframe is allowed moves to the new EmbeddedSourceValidator class, so that the filtering of the incoming requests and this sanitization agree on it. It now serves the media as well, through the new security.external.media.hosts.allowed property. That property is shipped with the * value, which allows any host and hence preserves the behaviour of the previous versions; setting it empty restricts the media to the ones Silverpeas hosts itself. The inlined images are kept whatever it is, being carried by the content itself. The mail path is deliberately left out: its images are referred by cid URLs, which such a sanitization drops, and its content isn't rendered in the Silverpeas origin anyway. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> 2026-09-28 14:37:15 +0200661dad84ee2e8251e0a0291c75876b2f91db5aefFix vulnerability #1459editcore-services/importExport/src/main/java/org/silverpeas/core/importexport/control/PublicationsTypeManager.javaeditcore-web/src/main/java/org/silverpeas/core/web/filter/IFrameChecker.javaeditcore-configuration/src/main/config/properties/org/silverpeas/util/security.propertiesaddcore-library/src/integration-test/resources/org/silverpeas/util/security.propertieseditcore-library/src/integration-test/java/org/silverpeas/core/test/WarBuilder4LibCore.javaeditcore-services/importExport/src/main/java/org/silverpeas/core/importexport/report/HtmlExportPublicationGenerator.javaeditcore-library/src/main/java/org/silverpeas/core/contribution/content/wysiwyg/service/WysiwygContentRenderer.javaeditcore-library/src/main/java/org/silverpeas/core/contribution/content/form/displayers/WysiwygFCKFieldDisplayer.javaaddcore-library/src/main/java/org/silverpeas/core/contribution/content/wysiwyg/service/directive/SanitizeForRenderingDirective.javaeditcore-library/src/integration-test/java/org/silverpeas/core/contribution/content/wysiwyg/service/WysiwygControllerIT.javaeditcore-library/src/test/java/org/silverpeas/core/contribution/content/wysiwyg/service/WysiwygContentTransformerTest.javaeditcore-library/src/main/java/org/silverpeas/core/contribution/content/wysiwyg/service/WysiwygContentTransformer.javaaddcore-api/src/main/java/org/silverpeas/core/security/html/EmbeddedSourceValidator.javaeditcore-api/src/main/java/org/silverpeas/core/util/security/SecuritySettings.javacore-library/src/main/java/org/silverpeas/core/util/HttpUtil.java5ebb4137a1e0058436d4e39ec80ec42a6b9c5f911790599035000https://integration.silverpeas.org/jenkins/user/mmoquillonMiguel Moquillonmiguel.moquillon@gmail.comFix vulnerability #1461 (GitHub issue, reported against 6.4.6) Let the callers of HttpUtil complete the HTTP client. Fixing that vulnerability requires the gallery component to request the image of a watermark with a connection timeout and without following the redirections, the latter being able to escape the verification of the address being requested. httpClientBuilder() gives the builder of the HTTP client, already configured with the proxy of Silverpeas, so that such a caller can complete the configuration without having to duplicate that of the proxy. httpClient() now delegates to it and is unchanged for its own callers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 2026-09-28 14:37:15 +02005ebb4137a1e0058436d4e39ec80ec42a6b9c5f91Fix vulnerability #1461editcore-library/src/main/java/org/silverpeas/core/util/HttpUtil.javacore-war/src/main/webapp/util/javaScript/silverpeas-fileUpload.jscore-web/src/main/java/org/silverpeas/core/web/filter/MassiveWebSecurityFilter.javacore-web/src/integration-test/java/org/silverpeas/core/web/filter/MassiveWebSecurityFilterOnReportedXssIT.java2ad38c6954d3170053da74aea7d4f47a06404d631790599035000https://integration.silverpeas.org/jenkins/user/mmoquillonMiguel Moquillonmiguel.moquillon@gmail.comFix the vulnerabilities CVE-2026-78738 and CVE-2026-78741 Both report a stored XSS through the name of an uploaded file, one from the document management and the other from the image upload of the WYSIWYG editor. They share their cause: the name is written as an HTML content by the upload widget, whereas it is carried by the request and escaped on the sending side only, which protects from nothing as a request can be forged. The name is now set as a text. Note the formatted size which followed it was already not displayed, html() taking a single argument, so the display is left unchanged. A scripting scheme given as the value of an attribute is detected as well by MassiveWebSecurityFilter. Such a declaration holds no on prefix and was therefore going through, and the colon introducing it is accepted written as the character itself or as any of the HTML entities standing for it, as the reported payload uses "javascript&colon;". The data scheme is deliberately left out: the contents do embed their inlined images with it. 2026-09-28 14:37:15 +02002ad38c6954d3170053da74aea7d4f47a06404d63Fix the vulnerabilities CVE-2026-78738 and CVE-2026-78741editcore-war/src/main/webapp/util/javaScript/silverpeas-fileUpload.jseditcore-web/src/main/java/org/silverpeas/core/web/filter/MassiveWebSecurityFilter.javaeditcore-web/src/integration-test/java/org/silverpeas/core/web/filter/MassiveWebSecurityFilterOnReportedXssIT.javacore-library/src/integration-test/resources/org/silverpeas/core/node/dao/nodes-sorting-dataset.sqlcore-library/src/main/java/org/silverpeas/core/node/dao/NodeDAO.javacore-library/src/integration-test/java/org/silverpeas/core/node/dao/NodeSortingIT.javacore-web/src/main/java/org/silverpeas/core/webapi/node/ListNodeResource.javabaa73a5b26b3e593c802c659e6d67799bb92a4001790599035000https://integration.silverpeas.org/jenkins/user/mmoquillonMiguel Moquillonmiguel.moquillon@gmail.comSort only the nodes of the component instance being administrated The sorting of the nodes was granted against the component instance referred by the URL of the REST service, whereas the nodes to sort were taken from the request body, each of them carrying the component instance it belongs to. An administrator of any instance could hence ask to sort the nodes of another one. The nodes are now identified within the instance of the URL, the one the authorization has been checked against. Taking that instance from the body brought nothing: the sorting applies by nature to the instance administrated. That wasn't enough though. NodeDAO was updating the order of a node by its identifier only, whereas such an identifier isn't unique by itself: the root node of every component instance is numbered 0, and the ones below it can bear the same numbers from an instance to another. So the instance of the node is now part of the criteria. Beyond the authorization, this was a defect on its own: sorting the nodes of an instance was renumbering the nodes of the other ones bearing the same identifiers, whoever asked for that sorting. NodeSortingIT covers the sorting of the nodes of an instance and the isolation of the other instances from it, in both directions. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 2026-09-28 14:37:15 +0200baa73a5b26b3e593c802c659e6d67799bb92a400Sort only the nodes of the component instance being administratedaddcore-library/src/integration-test/resources/org/silverpeas/core/node/dao/nodes-sorting-dataset.sqleditcore-web/src/main/java/org/silverpeas/core/webapi/node/ListNodeResource.javaaddcore-library/src/integration-test/java/org/silverpeas/core/node/dao/NodeSortingIT.javaeditcore-library/src/main/java/org/silverpeas/core/node/dao/NodeDAO.javacore-library/src/main/java/org/silverpeas/core/contribution/content/wysiwyg/service/directive/SanitizeForRenderingDirective.javae43a2cc2b84df2a3c699cc7d0bd7819f04af5c8e1790599035000https://integration.silverpeas.org/jenkins/user/mmoquillonMiguel Moquillonmiguel.moquillon@gmail.comTake into account sonarcloud feedback 2026-09-28 14:37:15 +0200e43a2cc2b84df2a3c699cc7d0bd7819f04af5c8eTake into account sonarcloud feedbackeditcore-library/src/main/java/org/silverpeas/core/contribution/content/wysiwyg/service/directive/SanitizeForRenderingDirective.javacore-configuration/src/main/config/properties/org/silverpeas/util/security.propertiescc844d33395f7b7d1b1167d15235cf636b5342931790599249000https://integration.silverpeas.org/jenkins/user/mmoquillonMiguel Moquillonmiguel.moquillon@silverpeas.comNow the parameter security.external.media.hosts.allowed is empty. This means all hosts out of Silverpeas will be refused in HTML media tags (video, iframe, img, ...) 2026-09-28 14:40:49 +0200cc844d33395f7b7d1b1167d15235cf636b534293Now the parameter security.external.media.hosts.allowed is empty.editcore-configuration/src/main/config/properties/org/silverpeas/util/security.propertiescore-library/src/main/java/org/silverpeas/core/index/indexing/parser/tika/TikaParser.javacore-library/src/main/java/org/silverpeas/core/index/indexing/model/IndexManager.javacore-library/src/main/java/org/silverpeas/core/index/indexing/parser/Parser.java50d31f738f19b3d7b37a86554870383fa9d856e21790608560000https://integration.silverpeas.org/jenkins/user/mmoquillonMiguel Moquillonmiguel.moquillon@silverpeas.comFix bug-15488 2026-09-28 17:16:00 +020050d31f738f19b3d7b37a86554870383fa9d856e2Fix bug-15488editcore-library/src/main/java/org/silverpeas/core/index/indexing/model/IndexManager.javaeditcore-library/src/main/java/org/silverpeas/core/index/indexing/parser/tika/TikaParser.javaeditcore-library/src/main/java/org/silverpeas/core/index/indexing/parser/Parser.javagitforums/forums-war/src/main/webapp/forums/jsp/modifyMessage.jspforums/forums-war/src/main/webapp/forums/jsp/viewMessage.jspforums/forums-war/src/main/webapp/forums/jsp/editMessageKeywords.jsp6d20d3540502e348e7b4716d788dc8eb1425d9b11790599054000https://integration.silverpeas.org/jenkins/user/mmoquillonMiguel Moquillonmiguel.moquillon@gmail.comFix vulnerability #1460 (GitHub issue of Silverpeas-Core, reported against 6.4.6) The title and the body of a forum message were printed raw by JSP scriptlets on the thread page, so any script posted by a user of the forum was run in the browser of every user reading it. The title is now HTML encoded on output, as the other JSPs of the component already do through WebEncodeHelper. Two other raw outputs of the title, which the report doesn't mention, are encoded as well: the one of modifyMessage.jsp, where the title lands in the value attribute of an input and is hence exploitable by escaping that attribute, and the one of editMessageKeywords.jsp. The body is sanitized by the applySanitizeForRenderingDirective directive introduced in Silverpeas-Core for the vulnerability #1459, which drops what can act on the visitor's browser while keeping the content as it is. Note the report also states the title pollutes the title element of the page. It does appear there, but viewMessage.jsp already prints it through a c:out tag, so it is encoded and isn't a vector. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> 2026-09-28 14:37:34 +02006d20d3540502e348e7b4716d788dc8eb1425d9b1Fix vulnerability #1460editforums/forums-war/src/main/webapp/forums/jsp/viewMessage.jspeditforums/forums-war/src/main/webapp/forums/jsp/editMessageKeywords.jspeditforums/forums-war/src/main/webapp/forums/jsp/modifyMessage.jspgallery/gallery-library/src/main/java/org/silverpeas/components/gallery/Watermark.javagallery/gallery-library/src/test/java/org/silverpeas/components/gallery/WatermarkTest.java508c8747e5b8116c0f642aa306a22a8ebb8c02641790599054000https://integration.silverpeas.org/jenkins/user/mmoquillonMiguel Moquillonmiguel.moquillon@gmail.comFix vulnerability #1461 (GitHub issue of Silverpeas-Core, reported against 6.4.6) The image of a watermark is an instance parameter any manager of the space holding the gallery can set, and the server requests it as it is, at each media creation. It could hence be pointed at a service the server keeps for itself. Such an URL is now verified before being requested: only the HTTP and HTTPS schemes are handled, and the host must resolve to neither a loopback nor a link-local address, so that neither the services bound to the server itself nor the metadata endpoint of a cloud provider can be reached. Every address the host resolves to is verified, otherwise a host resolving to a forbidden address beside an allowed one would go through. The addresses of the private networks of an organization remain reachable on purpose: they are where the internal resources of an intranet legitimately live, and no address range can tell them from the internal services one would rather protect. Only an explicit list of allowed hosts could, which is left to a further decision. The request is besides given a timeout and its response is no longer copied without any bound, both being able to exhaust the resources of the server, and the redirections are no longer followed as they would escape the verification above. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 2026-09-28 14:37:34 +0200508c8747e5b8116c0f642aa306a22a8ebb8c0264Fix vulnerability #1461addgallery/gallery-library/src/test/java/org/silverpeas/components/gallery/WatermarkTest.javaeditgallery/gallery-library/src/main/java/org/silverpeas/components/gallery/Watermark.javainfoLetter/infoLetter-war/src/main/webapp/infoLetter/jsp/previewLetter.jspinfoLetter/infoLetter-war/src/main/webapp/infoLetter/jsp/headerLetter.jspinfoLetter/infoLetter-war/src/main/java/org/silverpeas/components/infoletter/servlets/InfoLetterRequestRouter.java249c3e5a9115c7c560eae2043b256dddfab533781790599054000https://integration.silverpeas.org/jenkins/user/mmoquillonMiguel Moquillonmiguel.moquillon@gmail.comFix vulnerability #1462 and secure the other writings of the newsletter (GitHub issue of Silverpeas-Core, reported against 6.4.6) Publishing an issue of a newsletter changes its state, stamps its publication date, notifies the subscribers and mails the external ones. It was requested by a GET, and the synchronizer token is required on a GET only when its URL holds one of a few keywords, which ValidateParution holds none of. Any logged user lured into a cross-site visit was hence publishing the issue as themselves. The publication is now submitted by POST, on which the token is required whatever the URL, through the formRequest facility which stamps it. Moreover the endpoint had no role check at all, so any reader of the newsletter was able to publish an issue and to trigger the mailing, with no luring needed. Only its publishers and its managers can do so now. Three other writings, which the report doesn't mention, were exposed the same way and are secured likewise: - resetting the content of an issue with its template, which overwrites the content being written; - mailing an issue to oneself and to the managers, which sends the content of an issue not published yet and was hence a way for any reader to get a draft. As EditContent also serves the edition itself, a mere navigation which remains a GET, the reset is explicitly refused when it isn't requested by POST: submitting it by POST would otherwise protect nothing, the previous URL remaining requestable. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 2026-09-28 14:37:34 +0200249c3e5a9115c7c560eae2043b256dddfab53378Fix vulnerability #1462 and secure the other writings of the newslettereditinfoLetter/infoLetter-war/src/main/webapp/infoLetter/jsp/previewLetter.jspeditinfoLetter/infoLetter-war/src/main/java/org/silverpeas/components/infoletter/servlets/InfoLetterRequestRouter.javaeditinfoLetter/infoLetter-war/src/main/webapp/infoLetter/jsp/headerLetter.jspinfoLetter/infoLetter-war/src/main/webapp/infoLetter/jsp/listLetterUser.jspinfoLetter/infoLetter-war/src/main/java/org/silverpeas/components/infoletter/servlets/InfoLetterRequestRouter.javainfoLetter/infoLetter-war/src/main/webapp/infoLetter/jsp/listLetterAdmin.jspda97397bc61edab0e1f7156bdbf315ab641291131790599054000https://integration.silverpeas.org/jenkins/user/mmoquillonMiguel Moquillonmiguel.moquillon@gmail.comFix vulnerabilities #1463 (GitHub issue of Silverpeas-Core, reported against 6.4.6) The operations on the issues themselves were exposed the same way and are secured likewise: creating and modifying an issue, and modifying the headers of the newsletter, were requestable by a GET although their forms are submitted by POST, the router not caring about the method. None of the operations of this router had any role check, so any reader was able to write the content of an issue, to modify the headers of the newsletter, to delete issues and to read the ones being written. They are now reserved to the publishers and to the managers, but for the ones on the template and the deletion of several issues at once, reserved to the managers. Reading the inlined CSS rendering of an issue is how the readers get it from the list, so the criterion there isn't the role but the issue itself: it is refused to them as long as it isn't published. 2026-09-28 14:37:34 +0200da97397bc61edab0e1f7156bdbf315ab64129113Fix vulnerabilities #1463editinfoLetter/infoLetter-war/src/main/java/org/silverpeas/components/infoletter/servlets/InfoLetterRequestRouter.javaeditinfoLetter/infoLetter-war/src/main/webapp/infoLetter/jsp/listLetterAdmin.jspeditinfoLetter/infoLetter-war/src/main/webapp/infoLetter/jsp/listLetterUser.jspkmelia/kmelia-war/src/main/webapp/kmelia/jsp/publicationLinksManager.jspkmelia/kmelia-war/src/main/webapp/kmelia/jsp/basket.jspkmelia/kmelia-war/src/main/java/org/silverpeas/components/kmelia/servlets/ajax/AjaxOperation.javakmelia/kmelia-war/src/main/webapp/kmelia/jsp/orderTopics.jspkmelia/kmelia-war/src/main/java/org/silverpeas/components/kmelia/servlets/AjaxServlet.java217fe3edf581b66e5c9f935e9e367022e86977a61790599054000https://integration.silverpeas.org/jenkins/user/mmoquillonMiguel Moquillonmiguel.moquillon@gmail.comFix vulnerability #1464 (GitHub issue of Silverpeas-Core, reported against 6.4.6) Loading publications into the clipboard and pasting them under another topic were requestable by a GET, so any logged user lured into a cross-site visit was moving publications as themselves. The AJAX servlet of kmelia answers the GET as the POST, and none of its URLs holds any of the keywords making the synchronizer token required on a GET. So none of its operations was protected, including the deletion of publications which the report takes as protected: its URL does hold the delete keyword, but the rule applied to this servlet requires in addition the path to hold /jsp/, which the path of a servlet doesn't. The operations only reading something are now listed apart, every other one being taken as writing something so that adding an operation doesn't expose it by mistake, and a writing operation requested by a GET is refused. That refusal is performed before the processing, whose catch-all would swallow it. The user interface already submitted by POST the operations the report points at, as well as the deletion, the copy and the move of publications: what made the attack possible is the servlet accepting the GET. Three operations were still requested by a GET and are now submitted by POST: sorting the topics, emptying the trash from the basket, and binding a publication to another one. 2026-09-28 14:37:34 +0200217fe3edf581b66e5c9f935e9e367022e86977a6Fix vulnerability #1464editkmelia/kmelia-war/src/main/webapp/kmelia/jsp/basket.jspeditkmelia/kmelia-war/src/main/webapp/kmelia/jsp/publicationLinksManager.jspeditkmelia/kmelia-war/src/main/java/org/silverpeas/components/kmelia/servlets/AjaxServlet.javaeditkmelia/kmelia-war/src/main/java/org/silverpeas/components/kmelia/servlets/ajax/AjaxOperation.javaeditkmelia/kmelia-war/src/main/webapp/kmelia/jsp/orderTopics.jspkmelia/kmelia-war/src/main/java/org/silverpeas/components/kmelia/web/KmeliaResource.javakmelia/kmelia-war/src/test/java/org/silverpeas/components/kmelia/web/KmeliaResourceTest.javakmelia/kmelia-war/pom.xmlb7db955aa0a1cdeaf903b52ddce739e32d3836fd1790599054000https://integration.silverpeas.org/jenkins/user/mmoquillonMiguel Moquillonmiguel.moquillon@gmail.comFix vulnerability #939 (GitHub issue of Silverpeas-Components, reported against 6.4.6) Updating a publication was granted against the component instance referred by the URL, whereas the publication to update was entirely defined by the request body, which carries both its identifier and its component instance. Any user could hence rewrite the metadata of any publication of the platform by referring it in the body, the identifiers being enumerable. The publication is now refused when it doesn't belong to the instance the authorization has been checked against. Note the report states a WRITER role is required: it is not, the authorization of the REST framework only validating the access to the instance whatever the role played in it, so the exposure was wider than reported. Writing a publication, be it created or updated, now requires that role indeed. KmeliaResourceTest covers the checks. The war had no test at all, hence the test dependency added to its POM. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 2026-09-28 14:37:34 +0200b7db955aa0a1cdeaf903b52ddce739e32d3836fdFix vulnerability #939editkmelia/kmelia-war/src/main/java/org/silverpeas/components/kmelia/web/KmeliaResource.javaaddkmelia/kmelia-war/src/test/java/org/silverpeas/components/kmelia/web/KmeliaResourceTest.javaeditkmelia/kmelia-war/pom.xmldelegatednews/delegatednews-war/src/main/java/org/silverpeas/components/delegatednews/web/ListDelegatedNewsResource.javadelegatednews/delegatednews-war/src/test/java/org/silverpeas/components/delegatednews/web/ListDelegatedNewsResourceTest.javace910d20953d1f7a5129974ec71e8dfabfe1f9731790599054000https://integration.silverpeas.org/jenkins/user/mmoquillonMiguel Moquillonmiguel.moquillon@gmail.comReserve the management of the delegated news to the managers Modifying and deleting the delegated news is reserved to the managers of the application, as its user interface applies on its side. The REST service was granted against a mere access to the component instance, whatever the role played in it, so any of its users was able to reorder and to delete them by requesting it directly. Found while auditing the other REST resources against the flaw reported by the issue #939 of this repository. ListDelegatedNewsResourceTest covers the check. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 2026-09-28 14:37:34 +0200ce910d20953d1f7a5129974ec71e8dfabfe1f973Reserve the management of the delegated news to the managerseditdelegatednews/delegatednews-war/src/main/java/org/silverpeas/components/delegatednews/web/ListDelegatedNewsResource.javaadddelegatednews/delegatednews-war/src/test/java/org/silverpeas/components/delegatednews/web/ListDelegatedNewsResourceTest.javakmelia/kmelia-war/src/main/java/org/silverpeas/components/kmelia/servlets/AjaxServlet.javade9cf8606c9910989890a6d004cd47a8e2f611ca1790599054000https://integration.silverpeas.org/jenkins/user/mmoquillonMiguel Moquillonmiguel.moquillon@gmail.comTake into account sonarcloud feedback 2026-09-28 14:37:34 +0200de9cf8606c9910989890a6d004cd47a8e2f611caTake into account sonarcloud feedbackeditkmelia/kmelia-war/src/main/java/org/silverpeas/components/kmelia/servlets/AjaxServlet.javagithttps://integration.silverpeas.org/jenkins/user/mmoquillonMiguel Moquillonfalse570https://integration.silverpeas.org/jenkins/job/Silverpeas_Stable_AutoDeploy/570/