Fastjson 1.2.83 vẫn có thể kích hoạt thực thi mã từ xa mà không cần gadget truyền thống khi AutoType=false, đã được tái hiện trong môi trường cách ly JDK 8/17/21/25 + Spring Boot Loader.

Tác giả bài viết, nguồn: GCSA

Tóm tắt

Trong hệ thống phòng thủ lỗ hổng deserialization của Java truyền thống, ngành công nghiệp thường có những khoảng trống nhận thức sau: “AutoType bị tắt mặc định là an toàn”, “cố định tham số thứ hai của parseObject (loại mục tiêu cấp cao nhất) là an toàn”, “loại bỏ tất cả các phụ thuộc Gadget deserialization từ Classpath cục bộ là an toàn”. Tuy nhiên, những tiến bộ mới nhất trong攻防 đã hoàn toàn phá vỡ những suy nghĩ may rủi này.

GCSA Alliance hôm nay công bố độc quyền báo cáo phân tích kỹ thuật này. Báo cáo phân tích sâu sắc nguyên nhân cốt lõi khiến Fastjson 1.2.83, ngay cả khi AutoType=false ở trạng thái mặc định, vẫn có thể kích hoạt thực thi mã từ xa (RCE) mà không cần phụ thuộc vào Gadget truyền thống. Hiện tại, kỹ thuật khai thác này đã được tái tạo thành công toàn bộ trong môi trường cách ly JDK 8 / 17 / 21 / 25 và Spring Boot Loader. Lỗ hổng này không phải là “bypass danh sách đen để tìm Gadget cục bộ” như truyền thống, mà trực tiếp biến logic phát hiện metadữ liệu Class của chính Fastjson thành kênh lấy và cấp quyền cho Class độc hại từ xa. Dưới đây là nội dung chính

Tổ chức phát hành: GCSA - Liên minh An ninh Mạng Toàn cầu

Loại báo cáo: Phân tích kỹ thuật độc quyền / Báo cáo phân tích sâu về lỗ hổng

Ngày báo cáo: 2026-07-21

Trạng thái báo cáo: Đã hoàn thành kiểm toán mã nguồn và tái hiện trong môi trường cô lập

Mã lỗ hổng: Số hiệu nghiên cứu nội bộ FJ-GETRESOURCE-RCE (không tương ứng với CVE đã công khai)

Fastjson 1.2.83 vẫn có thể kích hoạt thực thi mã từ xa mà không cần gadget truyền thống khi AutoType=false, đã được tái hiện trong môi trường cách ly JDK 8/17/21/25 + Spring Boot Loader. Đề nghị kích hoạt SafeMode ngay lập tức và chuyển sang Fastjson 2.x.

1. Tóm tắt thực thi

ParserConfig.checkAutoType trong Fastjson 1.2.83 sẽ chuyển đổi giá trị @type do người dùng kiểm soát thành tên tài nguyên class và chuyển cho getResourceAsStream của ClassLoader hiện tại:

Trong môi trường ClassLoader fat-jar có thể phân tích tên tài nguyên URL tuyệt đối, kẻ tấn công có thể sử dụng dấu chấm để thay thế và tạo các URL http:, jar:http: và jar:file: để tải xuống class độc hại có @JSONType từ phía tấn công. Fastjson khi phát hiện chú thích này sẽ gọi loadClass và trả về trực tiếp class đó trước khi thực hiện kiểm tra lớp cơ sở nguy hiểm và kiểm tra tương thích loại mục tiêu. Khi class được tạo thể hiện và khởi tạo, mã tùy ý có thể được thực thi.

Việc khai thác này không phụ thuộc vào các gadget deserialization truyền thống đã có trong classpath mục tiêu và vẫn có thể kích hoạt trong trạng thái mặc định Fastjson AutoType=false. Việc cố định kiểu mục tiêu của JSON.parseObject không thể ngăn chặn việc thực thi; việc kích hoạt SafeMode có thể chặn đường dẫn khai thác bình thường trước khi truy cập tài nguyên.

Báo cáo này đã tái hiện thành công trong môi trường container Linux cô lập bằng cùng một payload JSON:

2. Đánh giá lỗ hổng

Không nên chỉ dựa vào phiên bản thành phần để đưa ra CVSS 9.8 đồng nhất: AppClassLoader thông thường là đối chứng âm, chuỗi đầy đủ trên JDK hiện đại còn phụ thuộc vào loader có thể phân tích hai URL JAR tuyệt đối và /proc/self/fd. Trong các ứng dụng đáp ứng môi trường tích cực của báo cáo này, tác động của lỗ hổng là RCE mạng không cần xác thực.

3. Phạm vi ảnh hưởng và điều kiện tiên quyết

• Xác nhận khi chạy: Fastjson 1.2.83
• Xác nhận JDK: 8, 17, 21, 25
• Xác nhận hệ điều hành: Linux; macOS cũng đã tái hiện JDK 17/21/25 bằng cách sử dụng /dev/fd
• Xác nhận loader: Spring Boot 2.7.18 classic loader + JDK 8; Spring Boot 3.2.0 loader + JDK 17/21/25
• Xác thực API: JSON.parse và JSON.parseObject với kiểu顶层 được cố định

Các phiên bản 1.2.68–1.2.83 trong mô tả bên ngoài phù hợp hơn để xem là phạm vi kiểm tra đã biết, thay vì phiên bản giới thiệu lỗ hổng. Việc kiểm tra mã nguồn cho thấy mã phát hiện tài nguyên class quyết định đã tồn tại từ phiên bản 1.2.67 và 1.2.68. Báo cáo này chỉ thực hiện xác minh đầy đủ trên mọi runtime JDK đối với phiên bản 1.2.83.

1. Kẻ tấn công có thể kiểm soát JSON được truyền vào Fastjson, và @type trong đầu vào sẽ được phân tích.

2. SafeMode chưa được kích hoạt.

3. ClassLoader của Fastjson có thể phân tích tên tài nguyên tuyệt đối đã được tạo thành URL.

4. Quá trình bị ảnh hưởng có thể kết nối với dịch vụ HTTP của bên tấn công.

5. Yêu cầu liên kết Linux hiện đại: /proc/self/fd phải có thể đọc được và bộ tải phải phân tích được

jar:file:/proc/self/fd/N!...。

1. JDK cần có khả năng tạo bộ nhớ đệm tạm thời JAR từ xa bình thường; điều này thường có nghĩa là thư mục tạm thời của JVM có thể ghi.

Người tấn công không cần:

• Ghi tệp vào classpath mục tiêu
• Mục tiêu classpath đã cài sẵn các gadget TemplatesImpl, JNDI, C3P0, Commons Collections
• Bật Fastjson AutoType
• Kiểm soát tham số thứ hai của JSON.parseObject

4. Phân tích nguyên nhân gốc

Vị trí mã nguồn:

Mã lõi:

Logic này giả định resource chỉ là đường dẫn classpath thông thường, nhưng không giới hạn giao thức, ngữ nghĩa đường dẫn tuyệt đối hoặc nguồn gốc của nó. Đối với fat-jar loader cụ thể, đầu vào sau sẽ trở thành URL tuyệt đối sau khi thay thế:

Do đó, getResourceAsStream tải tài nguyên mạng có thể bị kẻ tấn công kiểm soát do truy vấn siêu dữ liệu cục bộ vượt quá giới hạn.

Fastjson sử dụng ClassReader ASM riêng để phân tích nội dung tài nguyên:

Chỉ cần bên tấn công khiến lớp từ xa có chú thích @JSONType của Fastjson, thì jsonType sẽ được đặt thành true. Ở đây đang kiểm tra các byte do kẻ tấn công cung cấp, chứ không phải một lớp đã được tải từ classpath đáng tin cậy.

Vị trí mã nguồn:

TypeUtils.loadClass lần lượt thử loader rõ ràng, loader ngữ cảnh luồng và Class.forName. Trong môi trường thuận, loader ngữ cảnh luồng sẽ phân tích lại cùng tên tài nguyên tuyệt đối, tải class và thực thi defineClass.

Vị trí mã nguồn:

• Kiểm tra lớp cơ sở nguy hiểm sẽ không được thực hiện
• expectClass.isAssignableFrom(clazz) sẽ không được thực thi
• Loại ràng buộc dữ liệu cố định không thể ngăn thực thi trước khi khởi tạo class

Vị trí mã nguồn:

Kiểm tra SafeMode được thực hiện trước khi truy cập tài nguyên:

5. Giải thích chi tiết về chuỗi

Dạng ngắn nhất:

JDK 17+ cũng sẽ hoàn thành yêu cầu mạng, nhưng từ chối các đoạn đường trống trong tên nội bộ,

Phần tử đầu tiên của mảng payload đơn:

JDK 17+ sau đó từ chối tên nội bộ trong jar giai đoạn đầu: http://... nhưng Fastjson vẫn tiếp tục phân tích mảng do hậu tố Exception.

Các yếu tố ứng cử tiếp theo:

Lần khớp đầu tiên trong nhật ký class-load của JDK 17 là:

• JDK 8 trực tiếp chấp nhận jar giai đoạn 1: http://... class và thực thi
• Sau khi thực hiện lệnh trong lớp giai đoạn một, nó cố ý ném ra RuntimeException("stage-one-stop") để ngăn JDK 8 tiếp tục thử các FD socket/pipe không liên quan
• JDK 17+ thất bại do tên không hợp lệ trong giai đoạn đầu tiên trước khi khởi tạo class, sau đó mềm trả về thông qua Exception để vào giai đoạn liệt kê FD

6. Môi trường và bằng chứng tái hiện

Expected output:The script will:

• Biên dịch fat jar bị hại;
• Tạo JAR tấn công với class dành riêng cho FD;
• Tạo một payload là mảng JSON;
• Khởi động dịch vụ HTTP của máy tấn công trong mạng Docker được cô lập;
• Khởi động các container bị ảnh hưởng của JDK 8/17/21/25;
• Kiểm tra từng bản đồ container ra /tmp/fastjson-getresource-rce.

Burp chỉ chịu trách nhiệm gửi JSON đến các giao diện bị ảnh hưởng có điểm phân tích Fastjson; JAR tấn công vẫn cần được cung cấp bởi dịch vụ HTTP của bên tấn công.

Mẫu yêu cầu:

Nếu ứng dụng sử dụng kiểu cấp cao nhất cố định, có thể đóng gói mảng theo cấu trúc trường, ví dụ:

Thí nghiệm này sử dụng JSON.parseObject(json, BoundEnvelope.class) để phân tích gói trên, kết quả vẫn là RCE-OK và trả về BoundEnvelope bình thường.

Ưu tiên di chuyển sang Fastjson 2.x đang được bảo trì và xác minh lại tất cả cấu hình loại đa hình, AutoType và chế độ tương thích. Đừng chỉ thay thế JAR mà không thực hiện kiểm tra hồi quy.

Cấu hình mã:

Tham số JVM:

Lưu ý: Nếu ứng dụng đã đăng ký AutoTypeCheckHandler, cần đồng bộ kiểm tra hoặc gỡ bỏ vì handler sẽ được thực thi trước khi kiểm tra SafeMode.

• Đừng trực tiếp chuyển yêu cầu không đáng tin cậy cho JSON.parse/JSON.parseObject
• Từ chối mọi loại siêu dữ liệu đặc biệt tại cổng hoặc điểm vào ứng dụng
• Chỉ cố định kiểu Java cấp cao nhất không phải là hàng phòng thủ đầy đủ, vì các đối tượng lồng nhau vẫn có thể xử lý @type, và jsonType của lỗ hổng này đã trả về sớm để vượt qua kiểm tra tương thích

Ngăn chặn tạm thời các yêu cầu mà khóa JSON sau khi giải mã bằng với @type, và ghi đè tham số URL, thân yêu cầu và các đối tượng lồng nhau. Không chỉ tìm kiếm "@type" ở dạng văn bản thuần, Fastjson lexer sẽ giải mã tên trường trước, ví dụ:

Các quy tắc WAF chỉ có thể được sử dụng như một biện pháp giảm nhẹ, không thể thay thế việc nâng cấp thành phần và SafeMode.

1. Cấm JVM của doanh nghiệp khởi tạo kết nối HTTP/HTTPS đến các địa chỉ bên ngoài không cần thiết.
2. Áp dụng chính sách mạng tối thiểu cho container ứng dụng.
3. Hạn chế việc phơi bày /proc/self/fd hoặc sử dụng sandbox container nghiêm ngặt hơn khi tương thích.
4. Kiểm tra cách ClassLoader xử lý tên tài nguyên URL tuyệt đối, từ chối các định dạng giao thức như http:, https:, jar:, file:...
5. Theo dõi các hoạt động bất thường trong thư mục tạm JVM có tên jar_cache*

8. Đề xuất phát hiện và IOC

Tập trung vào các giá trị @type sau khi giải mã bao gồm:

Chỉ xuất hiện Exception không đủ để cảnh báo, cần kết hợp phân tích với định dạng giao thức, @type và các FD liên tiếp trong mảng.

• JVM yêu cầu tệp JAR hoặc .class không có phần mở rộng từ máy chủ bất thường
• Trong cùng một yêu cầu phân tích, xuất hiện 1–3 lần lặp lại GET/HEAD
• Đường dẫn yêu cầu có thể chứa /x, /a.class hoặc đường dẫn tương đương do kẻ tấn công tự định nghĩa

• Tạo thư mục tạm JVM với jar_cache*
• Quá trình Java mở lại tệp của chính nó thông qua /proc/self/fd/N
• log class-load xuất hiện tương tự:

9. Kết luận

Lỗ hổng này không phải là “bypass danh sách đen rồi tìm gadget cục bộ” truyền thống, mà là biến logic phát hiện metadata lớp của Fastjson thành kênh lấy lớp từ xa và cấp quyền. Việc @JSONType trả về sớm khiến lớp do kẻ tấn công cung cấp được chấp nhận trước khi kiểm tra lớp cơ sở nguy hiểm và ràng buộc kiểu; kênh mềm thất bại của Exception và bộ nhớ đệm tạm thời jar:http: của JDK đã mở rộng nguyên tắc tải trực tiếp của JDK 8 sang JDK 17/21/25.

Do đó, các phán đoán phổ biến sau đây đều không đúng:

• “AutoType bị tắt mặc định nên an toàn” — không đúng
• “Cố định tham số thứ hai của parseObject, do đó an toàn” — không đúng
• “Classpath không có gadget nào được biết đến, nên an toàn” — không đúng
• “JKD 17+ sẽ từ chối tên nội bộ có http://, nên chỉ có thể là SSRF” — không đúng



Trong các triển khai đáp ứng các điều kiện về loader đã xác minh, mạng và bộ mô tả tệp, vấn đề này có thể phát triển từ một yêu cầu JSON không xác thực thành thực thi mã từ xa. Nên ưu tiên di chuyển sang Fastjson 2.x và kích hoạt ngay SafeMode, đồng thời siết chặt các giới hạn kết nối ra ngoài và phân giải tài nguyên ClassLoader.

10. Đường dẫn tệp đính kèm và bằng chứng

Bản quyền và thông báo tái bản: Báo cáo này và các phân tích kỹ thuật liên quan do GCSA Alliance độc quyền phát hành. Nếu muốn sao chép, vui lòng giữ nguyên nguồn chính thức của GCSA và liên kết gốc, đồng thời không được sửa đổi ác ý các quan điểm cốt lõi của báo cáo.

Nguồn: GCSA Liên minh An ninh Mạng Toàn cầu

Trang web chính thức: www.gcsa.org