Hoppscotch phát hiện lỗ hổng "10 điểm", nguy cơ chiếm quyền máy chủ từ xa

[WhiteHat Team]

Một lỗ hổng bảo mật có mức độ nghiêm trọng tối đa (CVSS 10) vừa được công bố trong phiên bản tự triển khai của Hoppscotch, là nền tảng mã nguồn mở phổ biến dùng để phát triển, kiểm thử và quản lý API. Lỗ hổng có thể cho phép kẻ tấn công từ xa, không cần xác thực, chiếm toàn bộ quyền kiểm soát hệ thống chỉ bằng một yêu cầu HTTP duy nhất trong quá trình thiết lập ban đầu của máy chủ.
​

Điều đáng lo ngại là sau khi khai thác thành công, tin tặc có thể tự tạo token xác thực hợp lệ, đăng nhập với quyền quản trị cao nhất, truy cập toàn bộ dữ liệu của người dùng và duy trì quyền kiểm soát ngay cả khi quản trị viên đã thay đổi mật khẩu. Các chuyên gia đánh giá đây là một trong những lỗ hổng nghiêm trọng nhất từng được công bố đối với Hoppscotch.​

Hoppscotch là gì?​

Hoppscotch là nền tảng mã nguồn mở được nhiều lập trình viên và doanh nghiệp sử dụng để kiểm thử API, tương tự như Postman. Ngoài việc gửi và kiểm tra các yêu cầu HTTP, Hoppscotch còn hỗ trợ quản lý bộ sưu tập API, cộng tác theo nhóm, lưu trữ khóa truy cập (API Key), làm việc với GraphQL, WebSocket và nhiều giao thức khác.

Nhiều tổ chức lựa chọn triển khai Hoppscotch trên hạ tầng riêng nhằm kiểm soát dữ liệu nội bộ. Chính vì vậy, khi một lỗ hổng xuất hiện trên máy chủ backend, mức độ ảnh hưởng có thể lan rộng tới toàn bộ dữ liệu và người dùng của hệ thống.​

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

Lỗ hổng được định danh CVE-2026-50160, có điểm CVSS v3.1 đạt 10, mức cao nhất trong thang đánh giá mức độ nghiêm trọng của lỗ hổng bảo mật. Lỗi ảnh hưởng tới mọi phiên bản backend tự triển khai của Hoppscotch từ 2026.4.1 trở về trước.

Thông tin được Hoppscotch công bố thông qua GitHub Security Advisory GHSA-j542-4rch-8hwf vào ngày 28/5/2026. Theo công bố, nguyên nhân bắt nguồn từ một lỗ hổng thuộc nhóm Mass Assignment (CWE-915) trong API:​

POST /v1/onboarding/config​

Mass Assignment là kiểu lỗ hổng xảy ra khi ứng dụng tự động ghi nhận tất cả dữ liệu mà người dùng gửi lên, kể cả những trường dữ liệu vốn không được phép chỉnh sửa.

Nếu không được kiểm soát chặt chẽ, kẻ tấn công có thể chèn thêm các tham số nhạy cảm và khiến máy chủ vô tình thay đổi những cấu hình quan trọng.​

Nguyên nhân vì sao lỗ hổng xuất hiện?​

Các chuyên gia cho biết lỗ hổng không phải do một lỗi đơn lẻ mà là kết quả của nhiều sai sót trong thiết kế bảo mật kết hợp với nhau.

Trước hết, backend của Hoppscotch sử dụng framework NestJS với cơ chế ValidationPipe để kiểm tra dữ liệu đầu vào. Tuy nhiên, hệ thống lại không bật tùy chọn:​

whitelist: true​

Thông thường, tùy chọn này sẽ tự động loại bỏ mọi trường dữ liệu không được khai báo trước.

Do bị tắt, các tham số do hacker tự ý bổ sung vẫn được giữ nguyên và tiếp tục chuyển vào các lớp xử lý bên trong hệ thống.

Sau đó, dịch vụ xử lý cấu hình (infra-config.service.ts) lại duyệt qua toàn bộ các thuộc tính được gửi lên bằng Object.entries(dto) mà không kiểm tra xem chúng có hợp lệ hay không.

Tiếp theo, hàm validateEnvValues() cũng không chặn hai khóa cấu hình đặc biệt:​

• JWT_SECRET​
• SESSION_SECRET​

Hai giá trị này rơi vào nhánh xử lý mặc định (default) và được ghi trực tiếp vào cơ sở dữ liệu. Sai sót cuối cùng là API cấu hình ban đầu (onboarding) hoàn toàn không yêu cầu xác thực, miễn là hệ thống vẫn chưa hoàn tất bước khởi tạo đầu tiên. Khi kết hợp bốn điểm yếu này, kẻ tấn công có thể thay đổi các khóa bảo mật quan trọng của toàn bộ hệ thống.​

Cơ chế khai thác diễn ra như thế nào?​

Quá trình tấn công tương đối đơn giản nhưng mang lại hậu quả rất lớn. Đầu tiên, hacker gửi yêu cầu:​

GET /v1/onboarding/status​

để kiểm tra xem máy chủ Hoppscotch đã hoàn tất bước thiết lập ban đầu hay chưa. Nếu phát hiện hệ thống vẫn ở trạng thái khởi tạo (onboarding chưa hoàn thành), kẻ tấn công sẽ gửi tiếp một yêu cầu:​

POST /v1/onboarding/config​

Bên cạnh các thông tin cấu hình hợp lệ, yêu cầu này còn chèn thêm hai tham số do hacker tự tạo:​

• JWT_SECRET​
• SESSION_SECRET​

Do backend không lọc các trường dữ liệu ngoài dự kiến, hai giá trị bí mật này bị ghi đè lên cấu hình thật của hệ thống. Toàn bộ quá trình chỉ cần một yêu cầu HTTP duy nhất, không yêu cầu tài khoản, không cần vượt qua bất kỳ cơ chế xác thực nào.

Các nhà nghiên cứu đã xác nhận khả năng khai thác thành công trên một môi trường Hoppscotch AIO Docker mới cài đặt, đồng thời kiểm tra trực tiếp trong cơ sở dữ liệu để xác nhận các khóa bí mật đã bị thay đổi​

Vì sao việc ghi đè JWT_SECRET lại nguy hiểm?​

Trong các ứng dụng web hiện đại, JWT (JSON Web Token) được sử dụng để xác thực người dùng. Để đảm bảo token không bị giả mạo, hệ thống sẽ ký JWT bằng một khóa bí mật gọi là JWT_SECRET. Nếu hacker kiểm soát được khóa này, họ có thể tự tạo các JWT hoàn toàn hợp lệ cho bất kỳ tài khoản nào, kể cả tài khoản quản trị viên cao nhất. Nói cách khác, hệ thống sẽ tin rằng hacker là quản trị viên hợp pháp, không cần biết mật khẩu, không cần đánh cắp phiên đăng nhập, không cần vượt qua xác thực đa yếu tố (nếu việc xác minh chỉ dựa trên JWT).​

Hacker có thể làm gì sau khi chiếm quyền?​

Sau khi kiểm soát khóa ký JWT, hậu quả nhanh chóng leo thang.

Tin tặc có thể:​

• tự tạo token quản trị hợp lệ;​
• đăng nhập với quyền cao nhất;​
• truy cập toàn bộ Workspace của người dùng;​
• đọc và chỉnh sửa các bộ sưu tập API;​
• truy cập dữ liệu nhóm (Team);​
• lấy các API Key được lưu trong hệ thống;​
• khai thác các GraphQL API với đầy đủ quyền hạn.​

Bên cạnh đó, việc ghi đè SESSION_SECRET còn khiến toàn bộ phiên đăng nhập hiện tại của người dùng bị mất hiệu lực. Trong khi người dùng bị buộc phải đăng nhập lại, hacker lại có thể tự tạo các phiên đăng nhập mới theo ý muốn.​

Vì sao hacker vẫn giữ được quyền truy cập sau khi quản trị viên đổi mật khẩu?​

Đây là điểm nguy hiểm nhất của lỗ hổng. Thông thường, sau khi phát hiện bị xâm nhập, quản trị viên sẽ thay đổi mật khẩu để vô hiệu hóa tài khoản của hacker. Tuy nhiên, trong trường hợp này, hacker không phụ thuộc vào mật khẩu. Họ đang nắm giữ khóa bí mật dùng để ký JWT. Miễn là khóa này vẫn tồn tại trong cơ sở dữ liệu, hacker vẫn có thể tạo các token mới bất cứ lúc nào và tiếp tục đăng nhập với quyền quản trị.

Điều này đồng nghĩa với việc đổi mật khẩu không đủ để xử lý sự cố. Trong nhiều trường hợp, quản trị viên cần thay đổi lại toàn bộ khóa bí mật và triển khai lại hệ thống để loại bỏ hoàn toàn nguy cơ.​

Phạm vi ảnh hưởng​

Lỗ hổng chỉ ảnh hưởng tới phiên bản Hoppscotch tự triển khai. Các hệ thống có nguy cơ cao nhất là những máy chủ:​

• Vừa mới triển khai;​
• Chưa hoàn tất bước cấu hình ban đầu;​
• Được công khai trực tiếp trên Internet.​

Đây cũng là giai đoạn mà nhiều quản trị viên thường chưa kịp thiết lập các cơ chế bảo vệ bổ sung, tạo cơ hội thuận lợi cho kẻ tấn công khai thác.​

Đã có bản vá hay chưa?​

Hoppscotch đã phát hành phiên bản 2026.5.0 để khắc phục hoàn toàn lỗ hổng. Bản vá bao gồm nhiều thay đổi nhằm tăng cường bảo mật.

Đầu tiên, hệ thống đã bật hai tùy chọn quan trọng trong ValidationPipe:​

• whitelist: true​
• forbidNonWhitelisted: true​

Nhờ đó, mọi trường dữ liệu không được khai báo sẽ bị loại bỏ hoặc từ chối ngay từ đầu. Ngoài ra, nhóm phát triển còn:​

• chỉ cho phép cập nhật các khóa cấu hình nằm trong danh sách cho phép (allowlist);​
• bổ sung cơ chế từ chối rõ ràng đối với các khóa nhạy cảm như JWT_SECRET và SESSION_SECRET;​
• bảo vệ API onboarding bằng mã thiết lập một lần (one-time setup token), ngăn chặn truy cập trái phép trong quá trình khởi tạo hệ thống.​

Lỗ hổng được phát hiện bởi Kira thuộc Offgrid Security và ghi nhận công lao báo cáo cho nhà nghiên cứu infycore.​

Các chuyên gia khuyến nghị gì?​

Đối với các tổ chức đang vận hành Hoppscotch, các chuyên gia an ninh mạng khuyến nghị cần nhanh chóng thực hiện các biện pháp sau:​

• Nâng cấp backend Hoppscotch lên phiên bản 2026.5.0 hoặc mới hơn.​
• Không công khai máy chủ Hoppscotch trực tiếp trên Internet trong quá trình triển khai ban đầu.​
• Hoàn tất quy trình onboarding ngay sau khi cài đặt để thu hẹp "cửa sổ" có thể bị khai thác.​
• Kiểm tra lại giá trị của JWT_SECRET và SESSION_SECRET để bảo đảm chúng chưa bị thay đổi trái phép.​
• Nếu nghi ngờ hệ thống đã bị khai thác, cần thay mới toàn bộ khóa bí mật, thu hồi tất cả JWT đang hoạt động, yêu cầu người dùng đăng nhập lại và rà soát toàn bộ nhật ký truy cập để phát hiện dấu hiệu bất thường.​
• Đánh giá khả năng dữ liệu như API Key, Workspace và thông tin nhóm đã bị truy cập hoặc sao chép trái phép.​

Lỗ hổng CVE-2026-50160 là minh chứng cho thấy chỉ một sai sót trong quá trình kiểm tra dữ liệu đầu vào cũng có thể dẫn đến hậu quả đặc biệt nghiêm trọng. Việc kết hợp nhiều điểm yếu, từ lỗi Mass Assignment, thiếu xác thực trong giai đoạn khởi tạo đến cơ chế xử lý cấu hình không được kiểm soát, đã tạo điều kiện để kẻ tấn công chiếm quyền quản trị hệ thống chỉ bằng một yêu cầu HTTP.

Đối với các tổ chức sử dụng phiên bản tự triển khai của Hoppscotch, nguy cơ không chỉ dừng ở việc mất quyền kiểm soát máy chủ mà còn bao gồm khả năng rò rỉ toàn bộ dữ liệu API, khóa truy cập và thông tin cộng tác của người dùng. Do đó, việc nâng cấp ngay lên phiên bản 2026.5.0, kiểm tra tính toàn vẹn của các khóa bí mật và rà soát dấu hiệu bị khai thác cần được ưu tiên thực hiện để giảm thiểu rủi ro và đảm bảo an toàn cho hạ tầng phát triển API.​