InvoiceShelf đã phát hành bản vá cho CVE-2026-55610, một lỗ hổng nghiêm trọng cho phép bất kỳ chủ sở hữu (owner) nào ở một công ty có thể chiếm quyền điều khiển tài khoản người dùng ở một công ty khác. Lỗ hổng này, được xếp hạng 8.7 trên thang điểm CVSS, bắt nguồn từ việc thiếu kiểm tra phạm vi khách thuê (tenant-scope check) trong mã nguồn Laravel của ứng dụng.

Cách thức lỗ hổng hoạt động

InvoiceShelf là một công cụ SaaS được xây dựng trên Laravel, cho phép các công ty quản lý người dùng, hóa đơn và cài đặt từ một bảng điều khiển duy nhất. Nền tảng này đọc một header tùy chỉnh để xác định khách thuê (tenant). Khi một Chủ sở hữu (Owner) yêu cầu bản ghi người dùng, mã nguồn chỉ kiểm tra xem: “Người yêu cầu có phải là Chủ sở hữu của công ty họ không?”

Nó không bao giờ xác minh rằng người dùng mục tiêu thuộc cùng một khách thuê. Cơ chế route-model binding ngầm định của Laravel sẽ giải quyết ID người dùng thành một hàng trong bảng người dùng (users table) toàn cục, và chính sách ủy quyền sẽ phê duyệt yêu cầu chỉ dựa trên vai trò của người yêu cầu.

Do đó, một kẻ tấn công có thể:

  • Cung cấp bất kỳ ID người dùng bằng số nào trong URL yêu cầu.
  • Nhận được toàn bộ bản ghi người dùng, bao gồm cả email.
  • Thực hiện một lệnh cập nhật để ghi đè email, mật khẩu của nạn nhân và thậm chí gán lại tài khoản đó cho công ty của kẻ tấn công với quyền super-admin.

Trong thực tế, một Chủ sở hữu có ý đồ xấu đã biến một công cụ quản lý công ty thành một vũ khí chiếm đoạt tài khoản phổ quát. Không cần bất kỳ đặc quyền nào khác ngoài quyền “Owner”.

Những ai bị ảnh hưởng

Mọi khách hàng của InvoiceShelf đang chạy phiên bản trước 2.4.1 đều bị ảnh hưởng. Vì lỗ hổng nằm trong luồng xử lý yêu cầu cốt lõi, bất kỳ khách thuê nào cũng có thể trở thành mục tiêu của Chủ sở hữu thuộc một khách thuê khác, bất kể quy mô hay tình trạng bảo mật. Tác động bao gồm mất tính bảo mật (địa chỉ email) và mất tính toàn vẹn (thay đổi mật khẩu trái phép, nâng cấp lên quyền super-admin).

Bản vá

Các nhà phát triển đã phát hành phiên bản 2.4.1, bổ sung thêm bước kiểm tra khách thuê rõ ràng trước bất kỳ thao tác đọc hoặc ghi nào trên bản ghi người dùng. Bản sửa lỗi giới hạn phạm vi truy vấn theo định danh công ty đang hoạt động, buộc Laravel chỉ trả về các hàng thuộc về khách thuê của người yêu cầu.

Bài học cho các nhà phát triển

  • Không bao giờ dựa vào các khóa chính (primary keys) toàn cục trong các ứng dụng đa khách thuê (multi-tenant).
  • Áp dụng bộ lọc khách thuê cho mọi truy vấn cơ sở dữ liệu, không chỉ cho các hành động xóa hoặc tạo.
  • Thiết lập các chính sách ủy quyền để xác thực cả vai trò của người thực hiện và tính thuộc về khách thuê của đối tượng mục tiêu.
  • Coi các tính năng ngầm định của framework như route-model binding là những tiện ích có thể che giấu các lỗ hổng bảo mật trừ khi bạn thêm phạm vi (scoping) rõ ràng.

Nhìn về phía trước

Sự cố này cho thấy rủi ro rộng lớn hơn đối với bất kỳ dịch vụ SaaS nào sử dụng chung các bảng dữ liệu. Các cuộc kiểm tra bảo mật nên xem xét tất cả các endpoint chấp nhận các định danh và xác nhận rằng việc giới hạn phạm vi khách thuê được thực thi một cách đồng nhất.

Bài học rút ra: chỉ một lần thiếu kiểm tra khách thuê có thể biến một vai trò người dùng có đặc quyền thành một cửa sau (backdoor) phổ quát. Việc giới hạn phạm vi (scoping) phù hợp không phải là tùy chọn; đó là nền tảng của việc cô lập dữ liệu trong bất kỳ hệ thống đa khách thuê nào.