envoyproxy Envoy: Sai lệch canonicalization của path cho phép bypass RBAC authorization

Lưu ý: Dữ liệu này chỉ có tính chất tham khảo, phục vụ nghiên cứu an ninh mạng.CyStack khuyến nghị người dùng không sử dụng các thông tin này nhằm các mục đích bất hợp pháp

Lỗ hổng CVE-2026-73553 là gì?

Lỗ hổng CVE-2026-73553 là lỗ hổng Interpretation Conflict ảnh hưởng tới envoy (phiên bản bị ảnh hưởng: < 1.36.10, >= 1.37.0, < 1.37.6 và các phiên bản bị ảnh hưởng khác). Lỗ hổng này được xếp hạng ở mức Cao, với điểm CVSS 7.5. Lỗ hổng này đã có mã hoặc bằng chứng khai thác công khai, nhưng điều đó chưa xác nhận việc khai thác trong thực tế.

Giới thiệu chung

Dữ liệu gốc

Envoy là một edge proxy và service proxy mã nguồn mở được thiết kế cho các ứng dụng cloud-native. Trước các phiên bản 1.36.10, 1.37.6, 1.38.4 và 1.39.1, khi ignore_path_parameters_in_path_matching được bật, router của Envoy loại bỏ hậu tố dấu chấm phẩy trước khi matching nhưng RBAC url_path matcher lại đánh giá raw path. Do đó, một downstream request như /admin;x có thể không khớp DENY rule dành cho /admin trong khi router vẫn chọn protected /admin backend. Việc canonicalization không nhất quán cho phép client chưa xác thực bypass path-based authorization. Ranh giới phạm vi liên quan là route option và một path-based RBAC rule đều phải tồn tại, đồng thời protected route phải match sau khi stripping. Lỗi này được sửa trong các phiên bản 1.36.10, 1.37.6, 1.38.4 và 1.39.1.

Sản phẩm và phạm vi ảnh hưởng

Các branch và boundary được ghi nhận trong structured CVE facts:

  • envoyproxy/envoy phiên bản < 1.36.10.
  • envoyproxy/envoy phiên bản >= 1.37.0, < 1.37.6.
  • envoyproxy/envoy phiên bản >= 1.38.0, < 1.38.4.
  • envoyproxy/envoy phiên bản >= 1.39.0, < 1.39.1.

Các điều kiện cấu hình quan trọng là route bật ignore_path_parameters_in_path_matching, policy RBAC dùng path-based url_path, và protected route match sau khi path parameter bị loại bỏ. GitHub advisory cũng chứa nhãn rộng < 1.40.0 và mô tả mọi release hỗ trợ option là bị ảnh hưởng; nhãn này không hoàn toàn nhất quán với danh sách patched versions của chính advisory và các branch ranges có cấu trúc ở trên. Vì vậy, trạng thái của branch không nằm trong các ranges cụ thể cần được xác minh riêng thay vì suy luận từ nhãn rộng.

Chi tiết kỹ thuật

envoyproxy Envoy có hai thành phần xử lý request path theo cách không nhất quán khi ignore_path_parameters_in_path_matching được bật. Router sử dụng path đã loại bỏ phần hậu tố bắt đầu từ dấu chấm phẩy, trong khi RBAC url_path matcher vẫn đánh giá raw path. Vì vậy, một request như GET /admin;x có thể không khớp policy DENY dành cho /admin, nhưng vẫn được route tới backend được bảo vệ khi route match sau khi loại bỏ hậu tố.

Lỗi nằm ở sự khác biệt canonicalization giữa envoy.filters.http.router và envoy.filters.http.rbac, thuộc nhóm CWE-436. Điều kiện khai thác cần đồng thời có route option ignore_path_parameters_in_path_matching: true, policy RBAC dùng path-based url_path, và route được bảo vệ phải match sau khi phần path parameter bị loại bỏ. Vendor advisory mô tả router sử dụng sanitizedPath() và stripPathParams, còn RBAC giữ lại phần ; khi xử lý raw path. Các thiết lập chuẩn hóa path như normalizePath hoặc mergeSlashes không được vendor xác nhận là có thể khắc phục sự không nhất quán này.

Khả năng khai thác

Lỗi có thể bị kích hoạt từ downstream qua mạng bởi client chưa xác thực và không cần user interaction. Attacker chỉ cần gửi request có path chứa path parameter phù hợp, nhưng việc khai thác phụ thuộc chặt vào cấu hình route, policy RBAC và kết quả route matching nên không phải mọi triển khai Envoy đều bị ảnh hưởng.

Vendor advisory có kèm các tài liệu proof of concept cho tình huống này, vì vậy public exploitation material đã tồn tại. Evidence hiện có không xác nhận việc khai thác đang diễn ra trong thực tế hoặc gắn lỗi này với một campaign, nạn nhân hay breach cụ thể.

Tác động kỹ thuật

Kết quả kỹ thuật là path-based RBAC DENY rule có thể không được áp dụng trong khi router vẫn chọn protected route. Client chưa xác thực có thể khiến request vượt qua lớp authorization ở Envoy và tiếp cận tài nguyên hoặc thao tác của upstream service mà path policy intended to protect.

Tác động chính là mất confidentiality và integrity ở phạm vi mà protected backend cho phép; lỗi không được mô tả là gây mất availability. Mức độ ảnh hưởng cụ thể phụ thuộc vào các endpoint, dữ liệu và authorization bổ sung phía upstream. Phạm vi không phải mọi request hoặc mọi Envoy deployment, vì cần sự kết hợp chính xác giữa route option, RBAC path rule và route matching.

Tác động đến tổ chức

Một request bị bỏ qua policy path-based authorization có thể tiếp cận backend vốn chỉ được phép truy cập qua route được bảo vệ. Tác động thực tế phụ thuộc vào dữ liệu và thao tác mà backend cung cấp, nhưng có thể bao gồm lộ dữ liệu hoặc thực hiện thao tác trái phép nếu backend không có lớp authorization bổ sung.

Lỗi ảnh hưởng tới ranh giới kiểm soát truy cập giữa Envoy và upstream service, không phải cơ chế tạo thêm quyền quản trị trong Envoy. Các deployment không bật route option liên quan, không dùng path-based RBAC, hoặc không có protected route match sau canonicalization không đáp ứng điều kiện được mô tả.

Cách khắc phục

  1. Nâng cấp theo đúng branch bị ảnh hưởng lên release đã được xác nhận sửa lỗi tương ứng: 1.36.10, 1.37.6, 1.38.4 hoặc 1.39.1. Không suy luận rằng một release đã sửa tự động bao phủ mọi branch khác.
  2. Nếu chưa thể nâng cấp, xem advisory của vendor như không cung cấp configuration-only workaround được hỗ trợ cho lỗi này. Không dựa riêng vào normalizePath hoặc mergeSlashes, vì các thiết lập đó không loại bỏ path parameter theo cách cần thiết để đồng bộ router và RBAC.
  3. Rà soát lại các route và policy đang kết hợp ignore_path_parameters_in_path_matching với path-based RBAC. Nếu phải thay đổi thiết kế trước khi patch, cần kiểm thử riêng mọi protected route và xác nhận rằng cả authorization decision lẫn route selection đều dùng cùng một canonical path.
  4. Sau khi nâng cấp, chạy regression test trong môi trường kiểm thử với path bình thường và path có hậu tố sau dấu chấm phẩy. Xác nhận request bị policy xử lý đúng và không được chuyển tới protected backend ngoài ý muốn.
  5. Kiểm tra lại các bản phân phối hoặc sản phẩm đóng gói Envoy do nhà cung cấp khác xây dựng, vì version của gói downstream có thể không trùng trực tiếp với version upstream.

Cách phát hiện

  1. Kiểm kê tất cả triển khai Envoy và xác định branch, đặc biệt là các instance đứng trước những backend có dữ liệu hoặc chức năng cần authorization.
  2. Rà soát route configuration để tìm ignore_path_parameters_in_path_matching: true.
  3. Rà soát policy của envoy.filters.http.rbac để tìm các matcher url_path, nhất là policy DENY hoặc ALLOW dựa trên exact path, prefix hoặc path-based rule.
  4. Trong môi trường kiểm thử có kiểm soát, gửi các request path có và không có phần hậu tố sau dấu chấm phẩy, rồi so sánh kết quả authorization với route và upstream được chọn. Không coi việc request thông thường bị từ chối là bằng chứng rằng mọi biến thể path đều an toàn.
  5. Nếu access log đã ghi các trường tương ứng, đối chiếu raw request path như %REQ(:PATH)% với %ROUTE_NAME%, %UPSTREAM_CLUSTER%, %RESPONSE_CODE% và kết quả RBAC. Đây là tín hiệu điều tra và phát hiện sai lệch, không phải IOC đã được vendor xác nhận.
Nguồn (18)
Tìm hiểu thêm

Kiểm tra chuyên sâu cùng giải pháp quản lý rủi ro Web toàn diện

Giải pháp CyStack VulnScan liên tục phát hiện tài sản, xác minh lỗ hổng và giúp đội ngũ bảo mật ưu tiên khắc phục cho toàn bộ doanh nghiệp.