MCP ghi read-only vẫn cần một tài khoản database thật sự ít quyền
Một lỗ hổng vừa được vá trong MySQL MCP server của AWS cho thấy lớp chặn câu lệnh read-only không thay thế quyền thật của database account. Đây là ba lớp cần hiểu trước khi tiếp tục để agent truy cập dữ liệu.
Một MCP server có nút hoặc cấu hình read-only rất dễ tạo cảm giác rằng agent chỉ có thể đọc database. Nhưng với database, ranh giới cuối cùng không nằm ở nhãn của tool. Nó nằm ở quyền mà credential thật sự có khi kết nối tới MySQL.
Ngày 9/9/2026, AWS công bố CVE-2026-85788 cho awslabs.mysql-mcp-server. Theo security bulletin và GitHub Security Advisory của chính dự án, các phiên bản đến 1.0.21 có một lỗi trong cơ chế kiểm tra câu lệnh read-only. Trong một số điều kiện, lớp kiểm tra đó có thể bị vượt qua. Bản 1.0.23 đã sửa vấn đề.
Điểm đáng chú ý với người vận hành không phải kỹ thuật vượt bộ lọc. Chính AWS viết rõ rằng chế độ read-only ở MCP server là một best-effort safeguard, không thay thế quyền database được cấp đúng phạm vi. Boundary hiệu lực vẫn là quyền của MySQL user mà server đang dùng.
Nếu bạn đang cho Claude, Codex, Cursor hoặc một agent khác gọi MySQL qua MCP, sự cố này làm rõ ba lớp cần được nhìn riêng.
1. Phiên bản là lớp đầu tiên
Việc đầu tiên là xác định package nào đang chạy, thay vì hỏi agent rằng kết nối có an toàn hay không. Advisory áp dụng cho awslabs.mysql-mcp-server phiên bản 1.0.21 trở xuống và ghi bản vá ở 1.0.23.
Nếu hệ thống của bạn thuộc phạm vi đó, hành động trực tiếp là nâng lên 1.0.23 hoặc mới hơn theo hướng dẫn của AWS. Với fork hoặc image nội bộ, cần kiểm tra xem bản vá tương ứng đã thực sự được đưa vào build đang deploy hay chưa; chỉ đổi nhãn image không chứng minh code đã được cập nhật.
Đây cũng là một ví dụ về lý do không nên dùng prompt như một security control. Prompt có thể nói “chỉ chạy SELECT”, nhưng quyền thực thi cuối cùng vẫn do các lớp kỹ thuật bên dưới quyết định.
2. Quyền thật nằm ở MySQL user
Sau khi cập nhật package, câu hỏi quan trọng hơn là: credential này có thể làm gì nếu lớp kiểm tra của MCP server lại có lỗi?
AWS đặc biệt khuyến nghị database user chỉ có những quyền tối thiểu cần thiết và không giữ quyền FILE trừ khi thực sự cần. GitHub advisory cũng giải thích impact phụ thuộc vào việc database account phía khách hàng được cấp quyền quá rộng; trong trường hợp được mô tả, FILE là quyền làm hậu quả trở nên đáng kể hơn.
Vì vậy, tên tài khoản như mcp_readonly hay checkbox trong tool không nói lên quyền thật ở database. Một agent chỉ cần đọc bảng báo cáo không nên mặc nhiên kết nối bằng tài khoản quản trị, tài khoản migration hay credential dùng chung với ứng dụng production.
Một cách hiểu đơn giản là giả định lớp lọc ở MCP server biến mất trong một phút. Khi đó MySQL sẽ cho credential này làm gì? Câu trả lời cho biết boundary cuối cùng đang nằm ở đâu.
3. Phạm vi dữ liệu là một boundary riêng
Least privilege không dừng ở chuyện “được SELECT nhưng không được UPDATE”. Một tài khoản chỉ đọc nhưng nhìn thấy mọi schema vẫn có thể làm lộ nhiều dữ liệu hơn nhiệm vụ yêu cầu.
Nếu agent chỉ cần phân tích một tập bảng phục vụ support hoặc analytics, một user riêng chỉ có quyền đọc đúng schema hoặc view cần thiết tạo boundary rõ hơn việc đưa toàn bộ bảng cho agent rồi yêu cầu prompt “đừng đọc cột này”.
Credential cũng nên được hiểu theo môi trường. Một MCP server dùng cho local development không cần mặc nhiên cầm quyền trên production. Khi cần production access, đó là một cấu hình riêng, có owner và lý do rõ ràng.
Những boundary này không làm MCP server miễn nhiễm với lỗi. Chúng giới hạn hậu quả nếu một lớp kiểm tra phía trên thất bại.
Ba câu hỏi sau advisory
Sự cố này có thể được đọc bằng ba câu hỏi về trạng thái hệ thống:
Package đang chạy có nằm ngoài affected range không? Với advisory này, mục tiêu tối thiểu là 1.0.23 hoặc mới hơn.
MySQL user có đúng quyền cho nhiệm vụ không? Nếu nhiệm vụ chỉ cần đọc, account không nên có quyền ghi hay quyền hệ thống không cần thiết; AWS nhấn mạnh riêng việc tránh FILE nếu không có nhu cầu.
Account nhìn thấy đúng phần dữ liệu cần thiết không? Kiểm schema, table/view và môi trường mà credential có thể truy cập. Tên readonly không trả lời được câu hỏi này.
Ba câu trả lời tách rõ safeguard của MCP server khỏi boundary do database enforce.
CVE này không có nghĩa mọi MCP server đều nguy hiểm
Security bulletin của AWS nói về một package và một phạm vi phiên bản cụ thể. Nó không chứng minh mọi MCP server read-only đều có thể bị vượt qua, cũng không có nghĩa MCP bản thân là một cơ chế không an toàn.
Advisory cũng không nói AWS service bị mất tính bí mật hay toàn vẹn. AWS xác định đây là package mã nguồn mở, self-hosted phía client; khách hàng kiểm soát việc cài đặt và quyền của database credential.
Vì thế, phản ứng hợp lý không phải tắt mọi kết nối agent-database. Hãy vá đúng package nếu bạn dùng nó, rồi dùng sự cố này để hiểu lại kiến trúc quyền của chính mình.
Một lớp chặn câu lệnh trong MCP server vẫn hữu ích như defense in depth. Điều cần tránh là nhầm nó với lớp quyền cuối cùng đứng giữa một model có thể tạo truy vấn và dữ liệu trong database.
Nguồn
- AWS Security Bulletin 2026-103-AWS — CVE-2026-85788: xác nhận affected versions, bản vá 1.0.23 và khuyến nghị dùng database user với quyền tối thiểu; AWS nêu read-only mode là best-effort safeguard.
- GitHub Security Advisory GHSA-x25m-ph3m-3r9q của awslabs/mcp: mô tả phạm vi lỗi, điều kiện impact và nhấn mạnh quyền database mới là boundary hiệu lực.