此頁面列出 Spring 通報。
Spring Web Services 2.4.3、3.0.4 版本以及所有這三個專案的不受支援的舊版本，在接收來自不受信任來源的 XML 資料時，容易受到 XML 外部實體注入 (XXE) 的攻擊。
受影響版本的使用者應採取以下緩解措施
2019-01-14: 初次漏洞報告發布。
Spring Batch 3.0.9、4.0.1、4.1.0 版本以及不受支援的舊版本，在接收來自不受信任來源的 XML 資料時，容易受到 XML 外部實體注入 (XXE) 的攻擊。
受影響版本的使用者應採取以下緩解措施
2019-01-14: 初次漏洞報告發布。
Spring Integration (spring-integration-xml 和 spring-integration-ws 模組) 的 4.3.18、5.0.10、5.1.1 版本以及不受支援的舊版本，在接收來自不受信任來源的 XML 資料時，容易受到 XML 外部實體注入 (XXE) 的攻擊。
受影響版本的使用者應採取以下緩解措施
2019-01-14: 初次漏洞報告發布。
Spring Security 5.1.x 5.1.2 版本之前包含一個 JWT 頒發者驗證期間的授權繞過漏洞。要受到影響，必須使用誠實頒發者和惡意使用者的相同私鑰來簽署 JWT。在這種情況下，惡意使用者可以偽造帶有惡意頒發者 URL 的簽名 JWT，該 JWT 可能對誠實頒發者有效。
受影響版本的使用者應採取以下緩解措施
無需其他緩解措施。
此問題由 Björn Bilger 發現並負責任地報告。
Spring Framework 5.1 版本、5.0.x 5.0.10 版本之前、4.3.x 4.3.20 版本之前以及 4.2.x 分支上的不受支援的舊版本，在透過 ResourceHttpRequestHandler 提供靜態資源時，或從 5.0 版本開始，當帶註解的控制器返回 org.springframework.core.io.Resource 時，支援範圍請求。惡意使用者（或攻擊者）可以在 Range 頭部新增大量範圍、重疊的寬範圍或兩者兼有，以進行拒絕服務攻擊。
此漏洞影響依賴於 spring-webmvc 或 spring-webflux 的應用程式。此類應用程式還必須註冊以提供靜態資源（例如 JS、CSS、影像等），或擁有返回 org.springframework.core.io.Resource 的帶註解控制器。
依賴於 spring-boot-starter-web 或 spring-boot-starter-webflux 的 Spring Boot 應用程式開箱即用即可提供靜態資源，因此容易受到攻擊。
受影響版本的使用者應採取以下緩解措施
無需進一步的緩解措施。
評估影響時請注意以下事項
org.springfamework.core.io.Resource 的支援是在 5.0 版本中引入的。因此，5.0 版本之前的版本只能透過註冊提供靜態資源來受到影響。此問題由 Aruba Threat Labs 的 Nicholas Starke 發現並負責任地報告。
2018-10-16: 初次漏洞報告發布。
Spring Security OAuth 的 2.3 2.3.4 版本之前、2.2 2.2.3 版本之前、2.1 2.1.3 版本之前以及 2.0 2.0.16 版本之前，以及不受支援的舊版本，在某些條件下可能容易受到許可權提升的影響。惡意使用者或攻擊者可以精心構造對批准端點的請求，以修改先前儲存的授權請求，並在後續批准時導致許可權提升。如果應用程式配置為使用將 AuthorizationRequest 宣告為控制器方法引數的自定義批准端點，則可能會發生這種情況。
此漏洞影響滿足以下所有要求的應用程式
@EnableAuthorizationServer）AuthorizationRequest 宣告為控制器方法引數的自定義批准端點此漏洞不影響以下應用程式
@EnableResourceServer）@EnableOAuthClient）受影響版本的使用者應採取以下緩解措施
無需其他緩解措施。
此問題由 Micro Focus 的 Alvaro Muñoz (@pwntester) 發現並負責任地報告。
@EnableAuthorizationServer 的<a href="https://github.com/spring-projects/spring-security-oauth/blob/master/tests/annotation/approval/src/main/java/demo/Application.java#L36">配置示例</code></a>…spring-amqp 的 1.x 1.7.10 版本之前、2.x 2.0.6 版本之前存在中間人漏洞。
Spring RabbitMQ Java 客戶端不執行主機名驗證。
這意味著只要其他主機的 SSL 證書受到信任，就會被盲目接受。
要利用此漏洞，攻擊者必須在使用 Spring RabbitMQ Java 客戶端的 Java 應用程式與其連線的 RabbitMQ 伺服器之間執行中間人 (MITM) 攻擊。
TLS 通常可以保護使用者和系統免受 MITM 攻擊，但如果客戶端接受來自其他受信任主機的證書，則無法實現保護。
Spring AMQP 使用 RabbitMQ 的 amqp-client Java 庫與 RabbitMQ 進行通訊。
它使用 RabbitConnectionFactoryBean 建立/配置連線工廠。
受影響版本的使用者應採取以下緩解措施
此問題由瑞士 Alphabot Security 的 Peter Stöckli 發現並負責任地報告。
2018-09-11: 初次漏洞報告發布。
Spring Framework（5.0.x 5.0.7 版本之前、4.3.x 4.3.18 版本之前以及不受支援的舊版本）允許 Web 應用程式使用 Spring MVC 中的 HiddenHttpMethodFilter 將 HTTP 請求方法更改為任何 HTTP 方法（包括 TRACE）。如果應用程式存在預先存在的 XSS 漏洞，則惡意使用者（或攻擊者）可以使用此過濾器升級到 XST（跨站追蹤）攻擊。
受影響版本的使用者應採取以下緩解措施
無需其他緩解措施。
此攻擊適用於滿足以下條件的應用程式
此攻擊不能直接利用，因為攻擊者必須透過 HTTP POST 發起跨域請求，而這被同源策略禁止。因此，為了能夠升級到 XST 攻擊，Web 應用程式本身必須存在預先存在的 XSS（跨站指令碼）漏洞。
此問題由 Ocado Technology 的 Mariusz Łuciów 發現並報告。
2018-06-14: 初次漏洞報告發布。
Spring Framework 的 5.0.x 5.0.7 版本之前、4.3.x 4.3.18 版本之前以及不受支援的舊版本，允許 Web 應用程式透過 REST 控制器的 AbstractJsonpResponseBodyAdvice 和瀏覽器請求的 MappingJackson2JsonView 啟用 JSONP（填充式 JSON）跨域請求。Spring Framework 和 Spring Boot 預設都沒有啟用這兩項功能。但是，當應用程式中配置了 MappingJackson2JsonView 時，透過“jsonp”和“callback”這兩個 JSONP 引數，JSONP 支援會自動就緒，從而啟用跨域請求。
允許來自不受信任來源的跨域請求可能會將使用者資訊暴露給第三方瀏覽器指令碼。
此漏洞適用於滿足以下條件的應用程式
受影響版本的使用者應採取以下緩解措施
確實需要 JSONP 支援的應用程式在升級後需要明確配置 MappingJacksonJsonView 的 jsonpParameterNames 屬性。建議應用程式改用 CORS 而非 JSONP 來啟用跨域請求。Spring Framework 對 JSONP 的支援在 5.0.7 和 4.3.18 版本中已棄用，並將在 5.1 版本中移除。
此問題由 Meyyalagan Chandrasekaran 發現並報告。
spring-integration-zip 的 1.0.2 版本之前存在任意檔案寫入漏洞，可以透過精心構造的 zip 壓縮包（也影響其他壓縮格式，如 bzip2、tar、xz、war、cpio、7z）實現，該壓縮包包含路徑遍歷的檔名。因此，當檔名與目標解壓縮目錄拼接時，最終路徑會超出目標資料夾。先前的 CVE-2018-1261 阻止了框架本身寫入檔案。雖然框架本身現在不會寫入此類檔案，但它會將錯誤路徑提供給使用者應用程式，使用者應用程式可能會無意中利用該路徑寫入檔案。
這特別適用於解壓縮轉換器。
這隻有在使用此庫的應用程式接受並解壓縮來自不受信任來源的 zip 檔案時才會發生。
受影響版本的使用者應採取以下緩解措施
或者不要解壓縮不受信任的 zip 檔案。
此問題由 Snyk 安全研究團隊和 Abago Forgans 發現並負責任地報告。
2018-05-11: 初次漏洞報告發布
要報告 Spring 產品組合中專案的安全漏洞，請參閱安全政策
