An ninh không bắt đầu với việc tiết lộ CVE

Để tôi kể cho bạn một câu chuyện Có một phiên bản gọn gàng, gần như học thuật về cách bảo mật phần mềm được cho là hoạt động. Nó xuất hiện trong các cuộc hội thảo, tài liệu tuân thủ và trong các biểu đồ vui vẻ được nhìn thấy trên các trang chiếu tiếp thị. Một nhà nghiên cứu tìm thấy một lỗi, lặng lẽ (và chuyên nghiệp) báo cáo nó lên dòng, bản vá nó lên dòng, một CVE được chỉ định, người duy trì dưới dòng kéo sửa chữa, máy quét thông báo, người bảo vệ sửa chữa, và thế giới hầu hết vẫn ổn. Nếu đó thực sự là cách mọi thứ hoạt động, tôi sẽ không ở đây viết về các bản sửa lỗi, bản vá lỗi im lặng hoặc các vấn đề bảo mật tồn tại ở một nơi và biến mất ở nơi khác. - Và ai cũng cần biết. Rối loạn Những gì bạn sẽ học được trong bài viết này The Security Timeline Inversion: Làm thế nào CVE tiết lộ không phải là sự khởi đầu thực sự của thời gian bảo mật. Kết quả bảo mật: Tại sao các quyết định bảo trì thường xuyên, chứ không phải tốc độ phản ứng hoặc công cụ, quyết định kết quả bảo mật. Các chỉ số thiếu sót: Tại sao điểm số CVE, máy quét và thời hạn tuân thủ không phải là hệ thống cảnh báo sớm hiệu quả. Sự bóp méo lỗ hổng: Làm thế nào các thành phần nhúng, forked, và kết thúc cuộc sống che giấu sự hiển thị trong lỗ hổng và trách nhiệm. Những thay đổi cần thiết: Các thay đổi quản trị và vòng đời là cần thiết để tránh bị trì hoãn về mặt cấu trúc đối với các lỗ hổng "thinh lặng". Vào tháng 2 năm 2025, Apache Tomcat đã vận chuyển một bộ Họ đến mà không cần khẩn cấp, không có bình luận, và không có loại tiếng ồn có thể đi kèm với các sự cố an ninh đáng kể. Routine Đối với hầu hết các nhóm, không có lý do ngay lập tức để xử lý các bản phát hành này khác với các bản cập nhật bảo trì khác. Không có gì dường như bị hỏng. Không có gì dường như bị xâm phạm. Vài tuần sau, những phát hành tương tự đã trở thành trung tâm của một tình trạng khẩn cấp an ninh. Vào thời điểm CVE-2025-24813 được công bố vào tháng 3, con đường mã dễ bị tổn thương đã được xác định, sửa chữa và vận chuyển qua các chi nhánh Tomcat được hỗ trợ. Đối với tất cả những người khác, đó là một bất ngờ khó chịu: điểm số CVSS là 9,8 là một cách tuyệt vời để bắt đầu ngày của bạn. Cảm thấy tự do để kiểm tra các chi tiết của CVE ở đây Chúng tôi sẽ xem xét nội dung sau, vì những gì được ghi lại và ai ghi lại nó là một phần của câu chuyện này. Các chi tiết kỹ thuật khủng khiếp của CVE chủ yếu không liên quan. đặc điểm quan trọng là CVE này không xảy ra trong mode; nó phải được kích hoạt. https://nvd.nist.gov/vuln/detail/CVE-2025-24813 default https://nvd.nist.gov/vuln/detail/CVE-2025-24813 Dòng sự kiện này sẽ giúp chúng ta hiểu CVE có thể phát triển như thế nào và điều đó có thể ảnh hưởng đến người tiêu dùng như thế nào. Sự đảo ngược thời gian bảo mật Sự đảo ngược này là dễ dàng để bỏ lỡ nếu bạn chỉ nhìn vào ngày tiết lộ. thời gian bảo mật thường được nói như thể họ bắt đầu khi một CVE được xuất bản. Trong thực tế, họ bắt đầu sớm hơn. Khi vấn đề được báo cáo hoặc khi người bảo trì thay đổi mã. Khi một tên lửa trên sàn phóng bắt đầu đếm xuống, chúng ta thấy các động cơ khởi động trước khi tên lửa rời khỏi mặt đất. Đó là kiểu mô hình mà chúng ta thấy với CVEs. Trong trường hợp này, nhóm bảo mật của Tomcat đã làm theo một mô hình hoàn toàn bình thường cho cơ sở hạ tầng nguồn mở lâu dài. Một báo cáo tư nhân đã đến. Vấn đề đã được điều tra. Một sửa chữa đã được phát triển và vận chuyển. im lặng, và tất cả trước khi ‘rocket’ rời khỏi sàn. Mục đích không phải là bí mật mà là kiềm chế: mục tiêu là giảm cửa sổ trong đó người bảo vệ không có phản ứng khả thi. Thói quen vs. Hype Cách tiếp cận đó hoạt động tốt cho các tổ chức coi điểm phát hành là một cái gì đó để áp dụng. thói quen Những nhóm đó đã nâng cấp mà không biết lý do tại sao, và vào thời điểm lỗ hổng được thảo luận công khai, họ đã được bảo vệ. Đối với các tổ chức dựa vào việc tiết lộ như là động cơ kích hoạt hành động, March cảm thấy như một ngày không. Lỗ hổng dường như được hình thành đầy đủ, hoàn chỉnh với điểm nghiêm trọng, tuyên bố khai thác, v.v. Từ bên ngoài, dường như mọi người đều phải đối mặt với cùng một rủi ro cùng một lúc. Hai đội có thể đã chạy các phiên bản Tomcat giống hệt nhau vào tháng Giêng và kết thúc ở các vị trí rất khác nhau vào giữa tháng Ba. Một người bị cô lập, người kia bị phơi bày. Sự khác biệt không phải là tình báo mối đe dọa, công cụ hoặc nhận thức. Đó là Thói quen Giả định sai lầm của cảnh báo lớn Có một giả định kiên trì trong nhiều tổ chức kỹ thuật rằng các vấn đề bảo mật nghiêm trọng sẽ tự công bố đủ lớn để đòi hỏi sự chú ý. Giả định đó ngày càng không đáng tin cậy. Trong trường hợp này, chỉ số quan trọng nhất là không thể phân biệt được với bảo trì thường xuyên. Một mục nhập changelog. Một phiên bản bump. Một bản phát hành không cảm thấy khẩn cấp bởi vì không có gì đã nói với bất cứ ai rằng nó nên. Sau khi CVE được xuất bản, câu chuyện thông thường đã được thực hiện. lỗ hổng đã có tên, điểm số và đối tượng mục tiêu. Các cuộc thảo luận về mức độ nghiêm trọng, khả năng khai thác và cấu hình bắt đầu ngay lập tức. Ưu tiên thay đổi trước những câu chuyện Nó là cám dỗ để xem những phát hành tháng hai như là thời điểm may mắn. Họ đã không. Họ chỉ đơn giản là kết quả của một quá trình ưu tiên sửa đổi mã so với quản lý nhận thức. sự khó chịu đến từ nhận ra có bao nhiêu tổ chức đang Được cấu trúc để đáp ứng với những câu chuyện thay vì những thay đổi, với những tuyên bố thay vì những sự khác biệt. vô thức Vào thời điểm hệ sinh thái rộng lớn hơn bắt đầu tranh luận về những tác động của CVE-2025-24813, kết quả kỹ thuật đã được thiết lập. Làm thế nào CVE này (và thành thật mà nói, phần lớn tất cả các CVE) được triển khai trên toàn thế giới là một sự va chạm của các giải thích, đánh giá và nghĩa vụ Đó là nơi nghiên cứu trường hợp này trở nên thú vị và tạo ra một mẫu tuyệt vời như vậy. Đây là timeline chính Các yếu tố quan trọng đều xoay quanh thông tin CVE và CPE của NVD. . https://nvd.nist.gov/vuln/detail/CVE-2025-24813 https://nvd.nist.gov/vuln/detail/CVE-2025-24813 Tôi cần nhấn mạnh rằng điều này không nhằm mục đích gợi ý rằng bất cứ điều gì bất lợi đã xảy ra. Đây là một ví dụ làm việc về cách mọi thứ đang diễn ra. Tôi cần nhấn mạnh rằng điều này không nhằm mục đích gợi ý rằng bất cứ điều gì bất lợi đã xảy ra. Đây là một ví dụ làm việc về cách mọi thứ đang diễn ra. 13 tháng 1 năm 2025. lỗ hổng được báo cáo riêng tư Nhóm bảo mật Apache Tomcat nhận được một báo cáo riêng tư về một lỗ hổng liên quan đến các yêu cầu PUT HTTP một phần và servlet tệp mặc định. Ngày 24 tháng 1 năm 2025: Fix Committed. Ủy ban đã được ghi lại, và, như thường lệ và dự kiến, không có dấu hiệu nào cho thấy nó sửa chữa một lỗ hổng bảo mật. Yêu cầu kéo liên quan được đặt tên là "Nâng cao vòng đời của các tệp tạm thời được sử dụng bởi PUT một phần" https://github.com/apache/tomcat/commit/0a668e0c27f2b7ca0cc7c6eea32253b9b5ecb29c https://github.com/apache/tomcat/commit/0a668e0c27f2b7ca0cc7c6eea32253b9b5ecb29c 10 tháng 2 năm 2025: Fix được phát hành im lặng. Apache lặng lẽ phát hành Tomcat 9.0.99, 10.1.35, và 11.0.3 với sửa chữa bao gồm. đó là một tháng trước khi công bố công khai. tổ chức thường xuyên cập nhật được bảo vệ sớm. 10 tháng 3 năm 2025: CVE-2025-24813 Công khai Mục đích của công tác này là để đảm bảo an toàn cho người sử dụng, bảo mật cho người sử dụng, bảo mật cho người sử dụng, bảo mật cho người sử dụng, bảo mật cho người sử dụng ( ) trích dẫn https://nvd.nist.gov/vuln/detail/CVE-2025-24813 https://nvd.nist.gov/vuln/detail/CVE-2025-24813 “Vấn đề này ảnh hưởng đến Apache Tomcat: từ 11.0.0-M1 đến 11.0.2, từ 10.1.0-M1 đến 10.1.34, từ 9.0.0.M1 đến 9.0.98.” 13-14 tháng 3 năm 2025: khai thác PoC và các cuộc tấn công tích cực bắt đầu Trong vòng 30 giờ sau khi tiết lộ, các khai thác chứng minh khái niệm được phát hành công khai. Các nỗ lực quét hàng loạt và khai thác bắt đầu ngay lập tức. Phương pháp tấn công: tải lên JSP webshell thông qua phần PUT, kích hoạt thông qua yêu cầu JSESSIONID được thực hiện. Sources: Sonatype Blog | CyRisk Analysis 17 tháng 3 năm 2025: Một exploit POC được thêm vào hồ sơ CVE của NVD https://github.com/absholi7ly/POC-CVE-2025-24813/blob/main/README.md 18 tháng 3 năm 2025: Thông tin CPE đầu tiên được thêm vào CVE Các CPE là thông tin kỳ diệu mà làm cho CVE về cơ bản là máy đọc. Nó cho phép người tiêu dùng tự động của CVE 'biết' phiên bản của sản phẩm nào là dễ bị tổn thương. https://nvd.nist.gov/products/cpe https://nvd.nist.gov/products/cpe Tại thời điểm này, CPE chỉ đơn giản là phù hợp với tuyên bố phạm vi phiên bản ban đầu mà bạn đã thấy trước đó. 19–26 tháng 3 năm 2025: Phân tích nhà cung cấp bảo mật được công bố Rapid7, Akamai, Wiz, và Sonatype xuất bản các phân tích chi tiết. Rapid7 lưu ý rằng "không cần phải hoảng loạn" vì việc khai thác rộng rãi đã không được xác nhận và một số điều kiện tiên quyết của Apache đã được đánh giá quá cao. Sources: Rapid7 Blog | Akamai Blog | Wiz Analysis 1 tháng 4 năm 2025 :CISA thêm vào danh mục KEV CVE ghi nhận rằng CISA đã thêm CVE-2025-24813 vào danh mục các lỗ hổng được khai thác đã biết của mình, trích dẫn bằng chứng về việc khai thác tích cực.Các cơ quan liên bang Hoa Kỳ đã được đưa ra ngày 22 tháng 4 năm 2025, thời hạn để sửa lỗi.Amazon AWS cũng phát hành ALAS-2025-2812 cùng ngày. Sources: Keysight Analysis | Amazon Linux Advisories Đầu tháng 4 năm 2025: Enterprise Vendor Patches được phát hành Red Hat, Amazon, SUSE, Atlassian và các nhà cung cấp doanh nghiệp khác phát hành các bản vá. Hầu hết nhấn mạnh rằng cấu hình mặc định không dễ bị tổn thương vì servlet mặc định chỉ đọc. Sources: Red Hat CVE | Amazon CVE 3 tháng 7 năm 2025: Đơn vị 42 báo cáo 125K+ nỗ lực tấn công Đơn vị 42 của Palo Alto báo cáo 125.856 nỗ lực khai thác bị chặn chỉ trong tháng 3 năm 2025. Hầu hết lưu lượng truy cập khai thác dường như là "tạm thời" bằng cách sử dụng PoC công cộng của các diễn viên có độ tinh vi thấp. Source: Unit 42 Report Chúng ta đã xong chưa? Vâng, đối với một số người dùng Tomcat, những người trên phiên bản 9, 10 hoặc 11, mọi thứ đều ổn. 7 tháng 8 năm 2025 - CVE cập nhật "Các phiên bản EOL cũ hơn cũng có thể bị ảnh hưởng." Do một số hoạt động vận động hành lang do HeroDevs dẫn đầu, nhóm Apache đã thêm một cảnh báo. Điều này rất quan trọng. Điều này rất hiếm khi xảy ra, nhưng có những kỹ sư trong hỗn hợp tại Apache và các nơi khác cảm thấy cảnh báo là cần thiết. CPE đã được cập nhật, nhưng nó không nhận được bất kỳ thông tin nào về các phiên bản EOL, vì không có gì cụ thể để bao gồm. 8 tháng 8 năm 2025 - CVE Cập nhật với thêm thông tin về các phiên bản EOL CVE hiện tuyên bố, “Các phiên bản sau đây là EOL tại thời điểm CVE được tạo ra nhưng là được biết là bị ảnh hưởng: 8.5.0 đến 8.5.100.” Bây giờ CVE chính thức áp dụng cho một phiên bản khác của dòng Tomcat. Thật không may, CPE đã không được cập nhật. Hôm nay Ngay cả ngày nay, CVE này vẫn chưa được cập nhật để bao gồm thông tin CPE có thể giúp máy quét phát hiện một vấn đề trong phiên bản 8.5. Một số điều đó có thể được quy cho bản chất của CVE. Vì lỗ hổng chỉ có thể nếu một cấu hình mặc định được thay đổi. Thay đổi đến Lời bài hát: True readonly = giả Điều đó có nghĩa là, về mặt lý thuyết, khả năng khai thác phụ thuộc vào việc người dùng Tomcat có thể thực hiện thay đổi này.Nếu Tomcat được nhúng theo cách ngăn chặn cấu hình này thay đổi, thì sản phẩm “được nhúng” có thể đúng khi tuyên bố rằng họ không dễ bị tổn thương.Nhưng mặc định an toàn của một người là hack đơn giản hoặc bỏ qua của người khác. Ngoài ra còn có nhiều vỏ bọc và các biến thể thương mại của Apache Tomcat. Ví dụ, nó là một thành phần của Spring Boot, và Broadcom Tanzu cũng nhúng nó. Có bao nhiêu bình chất béo ở đó nơi thông tin thành phần đã bị mất, hoặc dự án POM đã được cập nhật kể từ khi vận chuyển? Làm thế nào thông điệp hòa tan Sự thật đắng đắng thường là báo cáo CVE và nhận được nhận thức thích hợp cho đúng người thất bại. Trên thực tế, một thành phần càng phổ biến để fork hoặc nhúng, nó có thể khó khăn hơn để tiếp cận những người cần biết về nó. Thường, trong sự nóng bỏng của khoảnh khắc, các nhà cung cấp tiếp cận cho báo cáo CVE ban đầu nhưng không trở lại để cập nhật. Nhảy múa chính xác tuyên bố rằng CVE áp dụng cho Tanzu và gán cho nó nhận dạng riêng của nó, TNZ-2025-014. Họ cảnh báo người dùng của họ rằng CVE được áp dụng cho các phiên bản 9,10 và 11, nhưng sau đó, như mọi khi, nó trở nên lộn xộn. bộ Tanzu phức tạp và phức tạp. Đột nhiên, CVE, thay vì đơn giản ' Tôi không biết nếu Tanzu có phiên bản với Tomcat 8 hoặc sớm hơn - tôi cho rằng họ làm. Do lời khuyên của họ là ngày 2025-03-25, lâu trước khi CVE có thêm thông tin phiên bản EOL bổ sung, người ta có thể đồng cảm với lỗi này, ngay cả khi nó có thể là một sự tiếp xúc lớn cho các sản phẩm Tanzu cũ hơn. Trang hỗ trợ are-you-exposed hoặc không Kịch bản chung Vào thời điểm CVE-2025-24813 có tên, điểm số và chu kỳ phương tiện truyền thông, kết quả đã khác nhau. Sửa chữa đã tồn tại trước khi CVE. Một số hệ thống được bảo vệ trước khi bất cứ ai biết lý do tại sao. những người khác sẽ tiếp tục tiếp xúc bất kể họ phản ứng nhanh như thế nào vào tháng Ba. Sự khác biệt đó không đến từ nhận thức, công cụ, hoặc bất kỳ thông tin về mối đe dọa nào. Nó đến từ thời gian. Chính xác hơn, từ giả định rằng bảo mật bắt đầu khi một lỗ hổng được tuyên bố, chứ không phải khi mã thay đổi lặng lẽ. Những gì tiếp theo không phải là một sự kiện duy nhất mà là một sự kiện kéo dài. Văn bản CVE đã phát triển. Dữ liệu CPE đến muộn và không đầy đủ. Lời khuyên của nhà cung cấp đã thay đổi phạm vi. Thời hạn tuân thủ đã làm cứng các sự thật một phần vào chính sách. Cập nhật về tiếp xúc EOL xuất hiện vài tháng sau đó, sau khi nhiều quyết định tiếp theo đã được đưa ra. Không có gì trong số này là độc hại. không có gì trong số đó là bất thường. Hệ sinh thái dễ bị tổn thương hiện đại cư xử khi nó đối xử với việc tiết lộ là một khoảnh khắc chứ không phải là một quá trình. Làm sao Nó đã xảy ra vào tháng Giêng, tháng Hai, tháng Ba, tháng Tám và hơn thế nữa.Tùy thuộc vào nơi bạn ngồi và tín hiệu bạn dựa vào.Thực tế khó chịu là vào thời điểm hệ sinh thái rộng lớn hơn đã kết thúc tranh luận về mức độ nghiêm trọng và khả năng khai thác, kết quả kỹ thuật đã được cố định. CVE-2025-24813 Bạn nên phản ứng như thế nào? Điều này có ý nghĩa gì với bạn và phải làm gì tiếp theo Cũng như tôi không thích thuật ngữ "sự thật không thoải mái", nó là thuật ngữ được sử dụng thường xuyên nhất trong những trường hợp này. tình huống là tất cả những gì chúng ta cần để giải quyết nó.Vì vậy, kết luận “không thoải mái” của nghiên cứu trường hợp này không phải là là bất thường nguy hiểm. nó là không có gì về cách nó được báo cáo và quản lý chấp nhận CVE-2025-24813 bất thường ở tất cả Các lỗ hổng không đến với bất kỳ fanfare. nó không tuyên bố mình là khẩn cấp. nó đã được giải quyết trước khi nó được đặt tên. các hệ thống sống sót đã làm như vậy không phải vì họ phản ứng nhanh hơn, nhưng bởi vì họ đã quyết định, lâu trước đó, làm thế nào họ sẽ đối phó với sự thay đổi. Nếu tư thế an toàn của bạn phụ thuộc vào Tại sao một bản cập nhật quan trọng trước khi bạn áp dụng nó, sau đó bạn đã hoạt động quá muộn. Biết Trong các hệ sinh thái hiện đại, sự giải thích đi theo hành động, chứ không phải ngược lại. Điều này có nghĩa là gì trong thực tế , tiết lộ không còn là sự khởi đầu của thời gian bảo mật. Vào thời điểm một CVE có được một tên, một điểm số, và cuối cùng là một thời hạn tuân thủ, công việc kỹ thuật quyết định thường đã xảy ra ở nơi khác. First Máy quét không cung cấp cho bạn cái nhìn trước; họ chỉ nói với bạn rằng bạn đã quá muộn. Second Cơ sở dữ liệu CVE, CPE, và catalog KEV là công cụ phối hợp. Chúng giúp các hệ sinh thái lớn di chuyển cùng nhau một khi một câu chuyện ổn định. không vào cơ sở mã của bạn, cũng không khi nó lặng lẽ rời đi. xử lý chúng như các hệ thống cảnh báo sớm tạo ra các đốm mù. Thực tế “Default safe” không phải là một chiến lược. Third Nhiều nhóm đã thoải mái với ý tưởng rằng lỗ hổng này đòi hỏi một cấu hình không mặc định. sự khác biệt đó sụp đổ vào thời điểm phân phối nhúng, fork, và triển khai JAR béo bước vào hình ảnh. Nếu bạn không thể chứng minh làm thế nào một thành phần được cấu hình trong sản xuất, bạn không thể dựa vào các giả định an toàn trên. Thói quen đánh bại anh hùng Sự khác biệt giữa các hệ thống được bảo vệ và bị phơi nhiễm trong câu chuyện này không phải là công cụ, tình báo mối đe dọa hoặc tốc độ phản ứng. Finally Những gì bạn nên làm tiếp theo Đừng chờ đợi CVE tiếp theo để kiểm tra các giả định này. bạn đã có đủ thông tin để hành động. bằng cách xác định các nguồn của các quyết định nâng cấp của bạn. Start Nếu các bản cập nhật được ưu tiên chỉ sau khi một lỗ hổng được đặt tên, ghi điểm hoặc ủy quyền, đó là một vấn đề quản trị và kiểm soát, không phải là một vấn đề kỹ thuật. Các quyết định được đưa ra, không phải công cụ nào được tham khảo. Khi Làm thế nào để xử lý "lặng lẽ" giải phóng. Examine Hỏi những điểm phát hành trong môi trường của bạn sẽ được áp dụng tự động, và những điểm nào sẽ bị hoãn cho đến khi được biện minh. Trách nhiệm đối với các thành phần cuối đời rõ ràng. Map Nếu một sự phụ thuộc không còn được hỗ trợ bởi dòng chảy trên, rủi ro không còn trừu tượng hoặc có niên đại trong tương lai. Trách nhiệm bảo mật đã thay đổi. Bây giờ nó ngồi với bạn, với một nhà cung cấp tiếp theo, hoặc với không ai. Tôi nên rõ ràng về vị trí của mình ở đây.Tôi làm việc cho một công ty cung cấp hỗ trợ mở rộng cho các thành phần mã nguồn mở cuối đời. Đó là một cách, đôi khi rất thực tế, để lấy lại quyền kiểm soát khi các lỗ hổng xuất hiện trong phần mềm cũ. Nó có thể mua không gian thở. Nó có thể ổn định một hệ thống đủ lâu để đưa ra quyết định hợp lý. (Những anh hùng) Nhưng nó không phải là lựa chọn duy nhất, cũng không phải là một sự thay thế cho sự hiểu biết về cách bạn kết thúc ở đây. Hỗ trợ mở rộng là một mạng lưới an toàn, không phải là một chiến lược. Vì vậy, có những nâng cấp tăng tốc, kiểm soát bù đắp, cách ly hoặc thay đổi kiến trúc. Tất cả chúng đều là các phản ứng hợp lệ trong các bối cảnh khác nhau. Chế độ thất bại thực sự không chọn bất kỳ phản ứng nào. Drifting vào một trạng thái mà không ai rõ ràng chịu trách nhiệm, và không có phản ứng thực sự thuộc sở hữu, là sự lựa chọn sai. End-of-life không có nghĩa là "không an toàn theo mặc định." Nó có nghĩa là gánh nặng của bằng chứng đã di chuyển. ai đó bây giờ phải tích cực chịu trách nhiệm bảo mật. Nếu bạn không thể chỉ ra đó là ai hoặc giải thích cách trách nhiệm đó được đáp ứng, thì rủi ro đã có mặt, cho dù một CVE có sự chú ý của bạn hay không. Hãy coi an ninh như một vòng đời, không phải là một sự kiện. Nếu quá trình của bạn chỉ tham gia vào thời điểm tiết lộ, bạn đang tối ưu hóa cho các câu chuyện, cho những câu chuyện, chứ không phải kết quả. Finally CVE-2025-24813 An ninh không bắt đầu từ thang máy Vào thời điểm đếm ngược đạt đến không, các động cơ đã được đốt cháy trong một thời gian dài. câu hỏi duy nhất là bạn đã nhận thấy, và liệu bạn đã xây dựng hệ thống của bạn để di chuyển trước khi ai đó nói với bạn tại sao.