{"schema_version":"1.0","service":"Publicasta","type":"article","id":572,"slug":"aws_mcp_database_servers_read_only_bypass_september_2026","title":"AWS исправила обход read-only в серверax MCP для баз данных: что нужно проверить операторам","excerpt":"Два бюллетеня AWS от 9 сентября показывают одну и ту же инженерную ошибку: текстовый фильтр SQL не равен границе доступа. В зоне риска самохостируемые MCP-серверы для PostgreSQL и MySQL.","language":"ru","default_language":"en","canonical_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=ru","image":{"url":"https://publicasta.com/storage/projects/17/pages/572/2026/09/dda7b4d7-2f7d-4716-88da-cc06ee10f526.webp","alt":"Абстрактная иллюстрация нейросети и базы данных, разделённых предупреждающими воротами, показывающая ограничения текстовых фильтров режима «только чтение»."},"publisher":{"id":17,"slug":"it_today_news","name":"ИТ сегодня","url":"https://publicasta.com/it_today_news"},"author":{"name":"Anton R"},"published_at":"2026-09-10T07:01:49+00:00","updated_at":"2026-09-10T07:01:49+00:00","content_markdown":"Два бюллетеня безопасности AWS, опубликованные 9 сентября 2026 года, резко конкретизировали проблему, о которой раньше было удобно говорить в общих словах: AI-инструмент с доступом к производственной базе данных не должен считать правило сопоставления строк последней линией обороны. Раскрытия касаются двух open-source, самохостируемых серверов Model Context Protocol из AWS Labs: одного для PostgreSQL и одного для MySQL. В обоих есть режим read-only, который должен был не дать ассистенту выполнять изменяющие SQL-запросы. В обоих случаях именно учетная запись базы данных остается тем контролем, который в итоге определяет, что реально может произойти.\n\n ![Абстрактная иллюстрация нейросети и базы данных, разделённых предупреждающими воротами, показывающая ограничения текстовых фильтров режима «только чтение».](https://publicasta.com/storage/projects/17/pages/572/2026/09/dda7b4d7-2f7d-4716-88da-cc06ee10f526.webp)\n\n Проблема PostgreSQL серьезнее. AWS присвоила [CVE-2026-87911](https://aws.amazon.com/security/security-bulletins/2026-104-aws/) слабости, которая при определенном сочетании версии пакета, метода подключения, привилегий в базе и действий пользователя могла позволить выполнение команд операционной системы. Исправление находится в версии 1.1.7.\n\n Раскрытие по MySQL, [CVE-2026-85788](https://aws.amazon.com/security/security-bulletins/2026-103-aws/), описывает другой сбой в проверке read-only: при некоторых условиях встроенные SQL-комментарии могли обходить фильтр. Затронуты версии пакета 1.0.21 и более ранние, а AWS указывает, что проблема устранена в 1.0.23.\n\n Это не уязвимости на стороне сервисов AWS в Aurora, RDS или другом управляемом контрольном плане AWS. Речь о клиентских пакетах, которые клиенты устанавливают и эксплуатируют сами. Для реагирования на инциденты это важное различие, но оно не делает бюллетени второстепенными. Эти пакеты соединяют AI-ассистента с базами данных, учетными данными и, в некоторых конфигурациях, с хостом, на котором работает сервер. Поэтому небольшая ошибка парсера может стать проблемой контроля доступа именно в точке, где запросы на естественном языке превращаются в операции с базой данных.\n\n ## Что раскрыла AWS\n\n Два бюллетеня вышли вместе, но описывают разные технические условия, поэтому разбирать их нужно отдельно. Если свести все к одной общей «уязвимости MCP», реакция станет менее точной.\n\n Для `awslabs.postgres-mcp-server` AWS сообщает, что версии до 1.1.7 содержат слабость OS command injection в компоненте SQL-валидации, отвечающем за соблюдение read-only. В бюллетене названа специально сформированная инструкция PostgreSQL `COPY ... TO PROGRAM` как релевантная возможность базы данных. В уязвимом развертывании содержимое, обрабатываемое при взаимодействии аутентифицированного пользователя с MCP-сервером, могло попасть на этот путь, хотя сам сервер работал в режиме read-only по умолчанию.\n\n Бюллетень не утверждает, что каждая установка удаленно эксплуатируема. Он выделяет более узкий профиль развертывания: самоуправляемый сервер PostgreSQL, использующий метод подключения `PG_WIRE_PROTOCOL`, и настроенную роль базы данных с привилегиями суперпользователя либо ролью `pg_execute_server_program`. Возможное последствие AWS описывает как выполнение команд операционной системы на хосте самоуправляемого сервера PostgreSQL. Слово «возможное» здесь существенно. Рекомендация фиксирует опасную уязвимость и условия, при которых она становится релевантной; она не устанавливает, что клиенты были атакованы.\n\n Собственная документация PostgreSQL объясняет, почему условие с привилегиями меняет тяжесть ситуации. Команда `PROGRAM` выполняется сервером базы данных, а не клиентом, и PostgreSQL ограничивает эту возможность суперпользователями или пользователями, которым выдана серверная роль для запуска программ. Иначе говоря, такая привилегия уже сама по себе мощная по замыслу. Слабость MCP важна потому, что она может позволить вводу пересечь границу, которую режим read-only в пакете должен был удерживать.\n\n Для `awslabs.mysql-mcp-server` AWS пишет, что версии по 1.0.21 включительно могут позволить выполнить оператор, который проверка read-only должна была заблокировать, если при определенных условиях используются встроенные SQL-комментарии. Бюллетень не описывает тот же путь к выполнению команд операционной системы, что и рекомендация по PostgreSQL. В нем сказано, что пакет является самохостируемым, а проблема не затрагивает конфиденциальность или целостность сервиса AWS. Практический риск в том, что учетная запись базы данных с более широкими правами, чем предполагалось, сможет выполнить запись, которую прикладная проверка пыталась отклонить.\n\n Первые операционные факты, которые нужно зафиксировать: PostgreSQL 1.1.7 или новее и MySQL 1.0.23 или новее. Не следует делать вывод, что обновление одного пакета исправляет другой. Это отдельные дистрибутивы с отдельными ветками выпусков, а в парке легко могут одновременно присутствовать оба.\n\n ## Почему формулировка read-only вызвала путаницу\n\n Многие инструменты для баз данных используют «read-only» так, будто это одно свойство. Это не так. За этой фразой скрываются как минимум три разных контроля.\n\n Первый — парсер или фильтр внутри приложения. Он смотрит на SQL-текст и отклоняет токены, связанные с записью, изменением сессии или другими чувствительными операциями. Это быстро и полезно для обратной связи пользователю. Такой слой может остановить обычные ошибки, например ситуацию, когда ассистент сгенерировал `UPDATE`, хотя пользователь просил отчет.\n\n Второй — режим сессии или транзакции в базе данных. У PostgreSQL и MySQL есть механизмы, которые могут ограничивать действия сессии, хотя точное поведение и исключения зависят от движка, метода подключения и учетной записи. Настройка на уровне сессии добавляет еще один слой, но все равно не заменяет привилегии учетной записи и должна проверяться на конкретной нагрузке.\n\n Третий — сама идентичность в базе данных: роль или пользователь, которые аутентифицируются на сервере. У этой идентичности есть grants, владение объектами, членство в ролях, доступ к хранимым процедурам и, возможно, особые серверные возможности. Это долговечная граница, потому что база оценивает ее уже после того, как запрос прошел через клиент, MCP-сервер, SQL-парсер и любую промежуточную политику.\n\n Текущий README AWS для PostgreSQL-сервера прямо говорит, что соблюдение read-only является best-effort защитой, а не границей безопасности. Он рекомендует выделенную роль базы данных и предупреждает против использования суперпользователя, `rds_superuser` или master user кластера. README MySQL формулирует ту же мысль: защита по SQL-тексту — это defense in depth, а реальной границей является настроенная роль базы данных.\n\n Эти раскрытия переводят документацию из теории в эксплуатационную практику. Текстовые фильтры работают с тем представлением, которое умеют распознавать. В SQL есть комментарии, quoted identifiers, условный синтаксис, хранимые процедуры, возможности отдельных версий, несколько операторов и поведение парсера, которое меняется со временем. LLM добавляет еще один источник вариативности: модель может создать необычный, но синтаксически корректный ввод, а на нее может повлиять содержимое, вернувшееся из базы данных или другого инструмента. От регулярного выражения нельзя ожидать моделирования всех этих взаимодействий.\n\n Поэтому безопасный дизайн задает два разных вопроса. «Отклонит ли MCP-сервер этот запрос?» — полезный вопрос для снижения случайных записей. «Если сервер его примет, что сможет сделать учетная запись базы данных?» — вопрос, который ограничивает ущерб. Второй ответ должен оставаться безопасным, когда первый контроль обойден, неверно настроен, устарел или просто неполон.\n\n ## Кому нужен срочный пересмотр\n\n Рекомендация по PostgreSQL наиболее важна для организаций, которые установили пакет AWS Labs до версии 1.1.7 и подключают его к самоуправляемому PostgreSQL через wire protocol. Роль базы данных требует немедленного внимания, если она является суперпользователем или имеет `pg_execute_server_program`. Развертывание с Aurora или другим управляемым профилем может не совпадать с заявленным в бюллетене затронутым профилем, но операторам все равно стоит обновиться: версии пакетов являются частью цепочки поставки ПО, а модель безопасности сервера применима шире, чем одно предварительное условие эксплуатации.\n\n Рекомендация по MySQL относится к установкам на версии 1.0.21 или более ранней. Поскольку пакет часто запускают через диапазон версий или плавающую ссылку `latest`, командам не стоит считать, что рабочая конфигурация сама показывает, какой код запущен. Нужно определить установленную версию из фактической клиентской среды, контейнерного образа, lockfile или артефакта развертывания. Результат лучше зафиксировать, а не полагаться на имя пакета в конфигурационном файле.\n\n Командам также нужно пересмотреть, как выбираются учетные данные. Документация AWS Labs описывает подключения, в которых AWS credentials используются для обнаружения ресурсов базы данных, а credentials из Secrets Manager — для аутентификации в самой базе. Поэтому MCP-сервер, подключенный к базе данных, может иметь две плоскости разрешений: AWS IAM permissions и database permissions. Ограничительная IAM-роль не делает логин базы данных автоматически read-only, а read-only роль в базе не мешает MCP-серверу читать чувствительные AWS metadata или локальные файлы, если окружающая конфигурация выдает такие возможности.\n\n Риск выше, когда сервер работает на рабочей станции разработчика, где также лежат исходный код, облачные credentials, SSH-материалы, build artifacts или браузерные сессии. Он выше и тогда, когда MCP-сервер доступен по сети, используется несколькими пользователями или запускается с широкими администраторскими credentials. Документация AWS API MCP Server, хотя она относится к связанному пакету, предупреждает, что локальная STDIO-модель предполагает одного пользователя и прямой доступ к хосту; там же сказано, что IAM остается основным контролем, а read-only классификации не гарантируют безвредность вывода команд. Для развертываний database MCP это тоже полезные архитектурные предупреждения.\n\n ## Первый ответ — инвентаризация, а не догадки\n\n Оператору, который реагирует на эти бюллетени, не нужно начинать с доказательства эксплуатируемости. Первая цель — установить, есть ли уязвимый код и условия по привилегиям. Короткая инвентаризация отвечает на большую часть важных вопросов.\n\n - Найдите каждую установку `awslabs.postgres-mcp-server` и `awslabs.mysql-mcp-server`, включая локальные конфигурации разработчиков, контейнеры, CI workers, shared jump hosts и упакованные IDE-среды.\n- Запишите точную версию, способ запуска, метод подключения, движок базы данных и профиль endpoint базы для каждой установки.\n- Сопоставьте пользователя или роль базы данных, используемые каждым сервером, с grants и membership. Отдельно проверьте PostgreSQL superuser status, `pg_execute_server_program`, административные привилегии MySQL, широкие grants на схемы, выполнение хранимых процедур и владение production-объектами.\n- Определите, работает ли сервер только локально или достижим по сети, а также могут ли несколько людей или tenants вызывать один и тот же процесс.\n- Проверьте, может ли сервер писать в базу данных, читать локальные файлы, вызывать cloud APIs или возвращать секреты в output инструмента.\n- Сохраните релевантные package manifests, container digests, историю конфигурации, authentication logs, database audit records и логи MCP-клиента до изменения среды.\n\n Смысл в том, чтобы собрать фактическую картину. Фразы «мы используем AI-ассистента» недостаточно для оценки проблемы. Самоуправляемый PostgreSQL с малопривилегированной reporting role — это один случай. Ноутбук разработчика, который использует master credential кластера против production-базы, — другой. При этом в обоих может фигурировать одно и то же имя пакета.\n\n ## Сначала обновление, затем снижение привилегий\n\n Немедленная мера исправления — обновление до версий, исправленных поставщиком: PostgreSQL MCP server 1.1.7 или новее и MySQL MCP server 1.0.23 или новее. Закрепите версию в том механизме, который реально запускает сервер. Если конфигурация использует `@latest`, широкий диапазон пакетов или незакрепленный container tag, следующее обновление может оказаться безопаснее, но текущее состояние останется трудно воспроизводимым и трудным для аудита. Используйте lockfile, immutable image digest или эквивалентный контролируемый механизм релиза.\n\n После обновления измените права в базе данных, если они шире, чем требует задача. Для отчетного workflow выделенная роль обычно должна иметь доступ только к нужной базе, схемам, таблицам, представлениям и узко выбранным routines. Документация PostgreSQL и README AWS Labs сходятся в одном: для такого рода интеграции не нужны суперпользователи и server-program privileges. Роль, которой нужно только читать утвержденные reporting views, не должна наследовать роль, способную администрировать кластер или выполнять программы на хосте базы данных.\n\n Тот же принцип действует для MySQL. README AWS Labs рекомендует выделенную учетную запись только с нужными grants, например `SELECT` на релевантную базу данных и `EXECUTE` только для специально одобренных процедур. Там же объясняется, что server-side filter рассчитан на перехват распространенных изменяющих операторов, но не может быть гарантией против всех краевых случаев грамматики или будущих возможностей SQL. Надежный отказ — это ошибка базы данных из-за отсутствующей привилегии, а не уверенное сообщение ассистента о том, что запись была заблокирована.\n\n Не стоит «исправлять» проблему более подробным prompt rule. Prompt instructions могут улучшить поведение, но они не являются контролем доступа. Steering files, system messages, approval lists и human confirmation prompts полезны в многослойном дизайне; ни один из этих элементов не должен быть единственным барьером, защищающим production data. Пользователь или внедренный документ может повлиять на текст, отправляемый модели, а модель может создать запрос, которого автор prompt не ожидал. Учетная запись, выполняющая запрос, все равно должна быть неспособна выйти за пределы задуманной области.\n\n ## Отдельно проверьте плоскость разрешений AWS\n\n Некоторые команды сосредоточатся на SQL-фильтре и пропустят AWS permissions, используемые MCP-процессом. README PostgreSQL говорит, что сервер может использовать AWS profile для обнаружения clusters или instances, а для пути RDS Data API ему может понадобиться permission to execute statements. В документированных конфигурациях он также использует Secrets Manager, чтобы получить credentials базы данных. Это отдельные решения, не равные grants пользователя базы.\n\n Используйте purpose-built IAM role или profile для процесса. Ограничивайте доступ к ресурсам там, где соответствующий AWS service это поддерживает, и не прикрепляйте administrator policies только потому, что ассистенту может понадобиться осматривать инфраструктуру. Руководство AWS IAM рекомендует least privilege, temporary credentials для workloads там, где это возможно, регулярный пересмотр неиспользуемых permissions и применение IAM Access Analyzer для уточнения политик по наблюдаемой активности.\n\n Важно помнить, что «read-only» на уровне AWS API не совпадает с «safe output». Некоторые операции чтения могут возвращать configuration, identifiers, policy documents или другие чувствительные материалы. Документация AWS API MCP Server говорит об этом прямо. Database assistant, который может объединять cloud discovery, secret retrieval, database queries и local file operations, получает намного большую фактическую власть, чем предполагают слова «SQL read-only».\n\n По возможности разделяйте функции. Инструмент, который отвечает на вопросы по утвержденным данным, не обязательно нуждается в праве создавать clusters, менять network controls, получать произвольные secrets или писать файлы. Если одному workflow нужны такие возможности, поместите их за отдельно одобренным инструментом и отдельной identity, а не добавляйте к универсальному reporting process.\n\n ## Проверьте использование уязвимых версий\n\n Рекомендации не устанавливают, что эти дефекты уже эксплуатировались в реальных атаках. Публичное обсуждение CVE не доказывает инцидент, а наличие уязвимого пакета не доказывает, что атакующий до него добрался. Тем не менее логи разумно проверить, потому что уязвимый путь связывает user-controlled content с поверхностью выполнения в базе данных.\n\n Для PostgreSQL просмотрите database logs и audit records на необычное использование server-side file или program features, неожиданные изменения ролей, создание незнакомых функций, изменения authentication configuration и активность MCP service account вне обычного шаблона запросов. На сервере базы данных проверьте host telemetry: процессы, файлы, сетевые соединения или persistence mechanisms, которые нельзя объяснить рабочей нагрузкой базы. Держите проверку на уровне defensive detection; не превращайте статью или incident ticket в инструкцию по воспроизведению command execution.\n\n Для MySQL проверьте операторы, которые должны были быть заблокированы, но появились в audit logs, неожиданные изменения production tables, использование administrative или file-related privileges, а также подключения MCP account с необычных clients или в необычное время. Где доступны записи, сопоставьте наблюдаемые SQL statements с natural-language requests, которые их породили. Несоответствие может указывать на prompt injection, слишком широкий tool contract, проблему парсера или обычную ошибку модели.\n\n CloudTrail может помочь с AWS-стороной расследования, но он не заменит telemetry базы данных и хоста. Ищите неожиданные Secrets Manager reads, RDS или cluster discovery вне нормального workflow, изменения IAM или security groups и доступ от identities, связанных с MCP-процессом. Сопоставляйте timestamps по MCP client, database, operating system и cloud logs.\n\n Если признаки указывают на unauthorized access, следуйте процессу incident response организации: изолируйте затронутый процесс, при необходимости ротируйте или отзывайте credentials, сохраняйте evidence и оценивайте целостность базы данных и хоста. Одного обновления недостаточно для полноценного реагирования, если привилегированный credential мог быть использован.\n\n ## Что это меняет в дизайне MCP-развертываний\n\n Непосредственные исправления — это обновления пакетов, но более широкий урок касается места, которое AI-интеграции разрешено занимать в архитектуре. MCP-сервер, переводящий естественный язык в SQL, не является просто удобным adapter. Это interpreter, помещенный между человеком, моделью, tool protocol и stateful system. Каждый слой может преобразовать запрос или добавить к нему смысл.\n\n Значит, нужны контроли, которые остаются понятными, когда модель ведет себя неожиданно. Полезное развертывание отделяет read-only analytics от operational database access. Оно использует роль базы данных, созданную специально для интеграции, ограничивает ее approved objects и оставляет production writes в workflow, где требуется отдельная identity и явный change process. Оно держит MCP-сервер локальным или иным образом изолированным, если продукт рассчитан на single-user STDIO operation. Оно ограничивает host, network egress, secrets и filesystem access вокруг процесса.\n\n Такое развертывание также делает versions и configuration наблюдаемыми. Команда должна уметь ответить, какой MCP package работал, с какими arguments, под какой identity, против какой database и какой tool call породил каждый query. Если этих ответов нет, раскрытие уязвимости приведет к долгому спору о том, что теоретически могло быть установлено, вместо быстрого решения по remediation.\n\n Тестирование должно покрывать реальный security contract, а не только happy-path query. Проверьте, что обычные read requests работают, unauthorized writes отказывают на уровне базы, процесс не может использовать privileged server features, errors fail closed, а malformed или unexpected input не отключает policy молча. Проверяйте поведение после dependency upgrades и после database engine upgrades. Цель не в том, чтобы доказать, что фильтр распознает каждое возможное написание SQL. Цель в том, чтобы доказать: недоверенный запрос не может выйти за пределы результата, разрешенного identity.\n\n ## Практический вывод\n\n Бюллетени AWS от 9 сентября вовремя напоминают: «read-only» — это проектное утверждение, которое должно обеспечиваться более чем в одном месте. Проблема PostgreSQL требует особого внимания там, где старый пакет подключен по wire protocol к самоуправляемому серверу с superuser role или `pg_execute_server_program`. Проблема MySQL затрагивает старые версии пакета и показывает, как SQL-синтаксис, безобидный для текстового фильтра, все равно может иметь значение.\n\n Обновите оба пакета там, где они присутствуют. Инвентаризируйте реальные версии запуска и методы подключения. Замените мощные учетные записи базы данных узко ограниченными ролями. Пересмотрите IAM profile, доступ к secrets, host permissions и network exposure вокруг MCP-процесса. Затем используйте логи базы данных, хоста и cloud, чтобы понять, были ли затронутые установки только уязвимыми или еще и использованными не по назначению.\n\n Долговечная рекомендация проста, даже если внедрение требует работы: пусть границу базы данных обеспечивает сама база данных. Model instructions и SQL filters следует считать полезными слоями вокруг этой границы, но не заменой ей.\n\n ## Источники\n\n - [CVE-2026-87911 - Read-only enforcement bypass enabling operating system command execution in the SQL validation component of Amazon awslabs postgres-mcp-server](https://aws.amazon.com/security/security-bulletins/2026-104-aws/) — Amazon Web Services, 2026-09-09T19:30:00Z.\n- [CVE-2026-85788 - Issue with awslabs mysql-mcp-server](https://aws.amazon.com/security/security-bulletins/2026-103-aws/) — Amazon Web Services, 2026-09-10T04:15:00Z.\n- [AWS Labs postgres MCP Server README and security model](https://github.com/awslabs/mcp/blob/main/src/postgres-mcp-server/README.md) — AWS Labs, 2026-09-10T00:00:00Z.\n- [AWS Labs mysql MCP Server README and security model](https://github.com/awslabs/mcp/blob/main/src/mysql-mcp-server/README.md) — AWS Labs, 2026-09-10T00:00:00Z.\n- [PostgreSQL COPY documentation](https://www.postgresql.org/docs/15/sql-copy.html) — PostgreSQL Global Development Group, 2026-08-20T00:00:00Z.\n- [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) — Amazon Web Services, 2026-09-08T00:00:00Z.\n- [AWS Identity and Access Management User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/iam-ug.pdf) — Amazon Web Services, 2026-01-15T00:00:00Z.\n- [aws-api-mcp-server: migration to AWS MCP Server](https://github.com/awslabs/mcp/issues/4115) — AWS Labs, 2026-07-10T00:00:00Z.","available_translations":[{"language":"ar","title":"تُصلح AWS تجاوزات وضع القراءة فقط في خوادم MCP لقواعد البيانات: ما الذي ينبغي على المشغّلين التحقق منه","html_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=ar","markdown_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=ar","json_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_mcp_database_servers_read_only_bypass_september_2026?lang=ar"},{"language":"de","title":"AWS behebt Umgehungen des Lesemodus in Datenbank-MCP-Servern: Was Betreiber jetzt prüfen müssen","html_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=de","markdown_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=de","json_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_mcp_database_servers_read_only_bypass_september_2026?lang=de"},{"language":"en","title":"AWS fixes read-only bypasses in database MCP servers: what operators need to check","html_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=en","markdown_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=en","json_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_mcp_database_servers_read_only_bypass_september_2026?lang=en"},{"language":"es","title":"AWS corrige bypasses del modo de solo lectura en servidores MCP de bases de datos: qué deben revisar los operadores","html_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=es","markdown_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=es","json_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_mcp_database_servers_read_only_bypass_september_2026?lang=es"},{"language":"fr","title":"AWS corrige des contournements du mode lecture seule dans des serveurs MCP de bases de données : ce que les opérateurs doivent vérifier","html_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=fr","markdown_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=fr","json_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_mcp_database_servers_read_only_bypass_september_2026?lang=fr"},{"language":"pl","title":"AWS naprawia obejścia trybu tylko do odczytu w serwerach MCP baz danych: co powinni sprawdzić operatorzy","html_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=pl","markdown_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=pl","json_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_mcp_database_servers_read_only_bypass_september_2026?lang=pl"},{"language":"ru","title":"AWS исправила обход read-only в серверax MCP для баз данных: что нужно проверить операторам","html_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=ru","markdown_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=ru","json_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_mcp_database_servers_read_only_bypass_september_2026?lang=ru"},{"language":"zh","title":"AWS 修复数据库 MCP 服务器的只读绕过问题：运营团队需要检查什么","html_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=zh","markdown_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=zh","json_url":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_mcp_database_servers_read_only_bypass_september_2026?lang=zh"}],"_links":{"self":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=ru","api":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_mcp_database_servers_read_only_bypass_september_2026?lang=ru","html":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=ru","canonical":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=ru","markdown":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=ru","json":"https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=ru","channel":"https://publicasta.com/api/public/v1/channels/it_today_news","channel_articles":"https://publicasta.com/api/public/v1/channels/it_today_news/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}