It is finally time to start reviewing 5GbE products. To kick us off, we have the BrosTrend 5GbE adapter. This is enabled by the newer Realtek RTL8126 chip, and provides a relatively inexpensive way to step up from 1GbE networking. Pricing varies, but we purchased ours for under $35, which makes it quite reasonable. Since […]
Не знам дали има друг град като Пловдив в историята на Google, който може да постигне един и същ резил за втори път, но нека отново да предупредя, че пак сме се запътили натам. Този път съдя за това по косвени белези, защото (за щастие) се дистанцирах от тази болна тема, но нека да разясня заглавието на този текст.
Кризисният PR на община Пловдив никога не е бил особено талантлив и когато се разчу, че Google Maps повече няма да показва данни за тукашния градски транспорт и медиите разшумяха казуса, първоначалната реакция на местната власт беше да замаже положението. Първата глупост беше, че нямали договор с Google. Втората, че имали свое приложение. Пази боже!
Чак в третата идея имаше някакъв рационален елемент. Два месеца по-късно успяха да върнат данните за Пловдив в Google Maps. Даже беше представено като иновация от някои местни подлизурчести медии.
Тогава премълчах, но сега ще споделя и това. Бяха взели последния комплект данни, които ние от „Тракия Тех“ бяхме направили, като вероятно са ги пипнали тук-там, и ги бяха дали отново на Google като актуализирани данни.
Как знам за това ли? Ами много просто… понеже бяха свършили работата като кучето на нивата, както обичаше да казва баба ми. И понеже не си бяха дали зор да попрегледат изискванията на GTFS, изведнъж (в уж актуализираните данни) се появиха едни странни автобусни линии, които Пловдив няма. Например 44w или 27rg.
Спирка пл. Съединение: Фантомни автобусни линии 44w и 22kСпирка Тунела – север-запад: Фантомни автобусни линии 44w и 27rg
Тези индекси са лично мое дело. Аз съм ги въвел, та си ги познавам. Така разбрах, че са взели нашите данни. Само, че тези индекси не трябва да се виждат, защото не са различни автобусни линии, а модификации на основните. Има няколко линии в града, които в определени дни или часове от деня се движат с модифицирани разписания или маршрути. Затова 44w всъщност е weekend версията на 44, а 27rg са няколкото коли, които вместо до Родина, се движат до Рогошките гробища (rg) и т.н. Схващате идеята. Само, че който се е погрижил за данните през август-септември 2024 не е схванал. И не е прочел достатъчно какво да прави.
Това, че са взели последния комплект от данни, които ние поддържахме не е лошо. Те са публични, а са такива, защото ние държахме да са отворени данни. Лошото е, че са взели един подреден комплект, който само трябваше да актуализират, а всъщност са го оплескали.
Данните с тези грешки и до ден днешен са online и всеки може сам да провери това по-горе. А опасенията ми са, че през 2024 година, в опит бързо да се замаже положението, са качени там някакви си данни и някой от ОКТ или общината е потвърдил пред Google, че те са актуални. Само, че вече сме 2026 година, а през последния месец доста активно използвах градски транспорт, трупайки наблюдения. Това, че разписанията не се спазват е ясно – те и не могат да бъдат спазени, защото не са съобразени с действителността в града. Но има грешки в маршрутите, в началните и крайните времена на тръгване на автобусите и в броя коли, които ги изпълняват. А това Google го разбира, защото „вижда“ движението на телефоните на пътниците по всеки маршрут.
Подозирам и че след извънредния напън през 2024 година да се върнат някакви данни онлайн, след това отново никой не се грижи да ги актуализира. А Google трупа статистика за тези разминавания. И следи дали и кога последно някой е опреснявал данните. Така вероятността Пловдив отново да изпадне от Maps никак не е малка.
През същата 2024 година – т.е. преди малко повече от година – на годишната „Среща на бизнеса от Пловдив, Пазарджик и региона“ бях модератор на панела за дигитализация и транспорт, където от сцената се чуха амбициозни идеи и планове за следващата година. Тя обаче отмина, а нито в посока дигитализация, нито в посока обществен транспорт се забелязва някаква положителна промяна.
Ако има някаква добра новина от последните няколко месеца, тя е, че сякаш поне повече автобуси обслужват линиите на градския транспорт. Но на електронните табла по спирките информацията е все по-оскъдна, до степен да е безполезна. Системата за електронно таксуване е все така доникъде. Някак и нещо работи, но така и нищо не бе официално обявено. Таксуващите устройства (където изобщо ги има) много често не са активни. Шофьорите се правят на три и половина, че не разбират и не е тяхна работа, защото имат интерес да продават хартиени билетчета. И да ги препродават по няколко пъти. А контролът е близко до никакъв.
Автобусите преобладаващо са стари и мръсни. Жегата през лятото е сериозна, а климатиците (когато работят) се пускат колкото за отбиване на номера. Доста от водачите са крайно груби, шофират опасно и пропускат спирки. Разписанията, както вече отбелязах са само пожелателни, а напоследък и трудно откриваеми, освен на сайта на общината, който никой няма желание да гледа.
В този ред на мисли, особено за гости на града, който има претенции да бъде и туристическа дестинация, актуалната информация в Google Maps продължава да бъде повече от пътеводна светлина. Дори с несъвършенствата си.
В края на същата 2024 година бях за седмица на гръцкия остров Корфу. Остров. В Йонийско море. С около 100 хиляди души население. И с безупречен обществен транспорт. Билети и карти могат да се купят от автомати по спирките, плащайки в брой или с карта. Билетите и картите могат да се презареждат с допълнителни пътувания, а интерфейсът на машините може да се превключва на 5-6 езика. В автобусите винаги се качваш от първа врата и валидираш билет или карта при шофьора. Ако нямаш, може да се таксуваш в брой или с банкова карта (но малко по-скъпо) при шофьора. Той е в униформа. И задължително се поздравявате взаимно.
Автобусите са чисти и нови. Всяка предстояща спирка се обявява на дисплей с времето до достигането ѝ. На някои по-нови автобуси се обявяват до три предстоящи спирки. Климатиците работят така, че може да се простудиш.
По спирките има разписания на хартия и QR код, който води до електронната им версия, заедно с информация след колко точно минути идва следващия автобус на точно тази спирка.
В Google Maps сe показват не само маршрутите и разписанията, но и движението на автобусите в реално време (с евентуалните закъснения – дори до минута или две) – нещо, което в Пловдив сигурно ще стане възможно след още едно хилядолетие. Пловдивчани сме айляк, за къде да бързаме толкова…
Ранна зимна сутрин. Софийско училище. Родители изпращат децата си. Водят ги за ръчичка, целуват ги по челата, подават им кутиите с обяда, казват им по нещо, изпращат ги с поглед, докато тежката училищна врата се затваря зад гърбовете им.
И в тези десет минути преди първия час има толкова много нежност и надежда, и любов, че ако човек остане сам със себе си като страничен наблюдател някъде покрай това училище, може и да се залъже, че всичко е наред.
После нещо става. Ръцете се пускат. Кутиите за обяд стават 5 евро за дюнер и енергийна напитка. Никой не се прегръща и целува. Вратата все по-рядко се затваря зад гърбовете на учениците, защото повечето от тях дори не искат да влязат в сградата.
Най-голямото предателство към децата ни е образователната система, в която ги оставихме да се давят. Сцила, Харибда и Янка Такева дебнат отвсякъде. С празнодумните поздравителни адреси за началото на учебната година, застинали в 76-та; с институционалните проверки, симулиращи дейност и никога неразкриващи никакви нарушения; с декларативната важност на документи и стандарти, които ни убеждават, че ще развиваме критично и самостоятелно мислене, а после пак караме децата да дават „правилни“ отговори през наизустени кухи дефиниции.
Тези, които успяват да излязат на сушата, често са осакатени от борбата с морските чудовища. А други така и не доплуват до отсрещния бряг.
През изминалата седмица стана ясно, че едно 18-годишно момче се е самоубило вероятно заради учителски тормоз. Според съучениците му Билгин Алишев от баташкото село Нова махала е сложил край на живота си вследствие на системни обиди и подигравки от преподавателката по английски Елихан Хаджийска.
Момчето е споделяло и е давало сигнали, че е подлагано на тормоз. В деня, в който се самоубива, е бил на „комисия“, разследваща поведението му. Според приятелите му не е имал възможност да се изкаже и не е получил защита от възрастен, с изключение на един от учителите.
Историята на Билгин не е прецедент. Това се случва и в малки населени места, и в столицата, включително в училища с много добра репутация (каквото и да означава това на фона на цялата янкатакевщина). И примиряването с подобна система на образование е най-големият обществен провал на този иначе „много древен, мъдър и изстрадал народ“ (по Ивелин, Костадин, Радостин или друг, завършващ на -ин).
Същият този народ се е запътил бодро към настъпването на поредната мина на 631-вите избори за последните 5 години.
Преди това очаква с нетърпение КОЙ ще бъде служебният премиер. Голямо чакане, голямо нещо. То са разговори, то е чудо. Сърцето ми може и да не издържи на напрежението, докато дебне за новината, че Главчев пак ще е премиер.
Но нека президентката да каже. А дотогава, за да не ви е скучно, вижте защо фактът, че имаме жена президент, не е нещо особено показателно за отношението ни към жените и мястото им в българската политика. В статията си „Имаме си президентка. И?“ Светла Енчева разглежда точно това.
За чакането и гласуването като национален спорт, за турнето на Бойко Борисов по медии и инфлуенсъри и разбира се, за международното положение е новият епизод на „Т.Е. от Е.Т.“, в който освен всичко друго Е.Т. призовава да се купува „Тоест“. С други думи – да се абонирате с месечно дарение, за да може „Тоест“ да продължи да съществува, в случай че имате нужда от това.
Традиционният петъчен политически анализ на Емилия Милчева е посветен на служебния премиер и Изборния кодекс, с които ще разполагаме, за да проведем едни „честни избори“.
Равноотдалечеността е химера. Правителство, чийто премиер се избира измежду политически назначения, били те и високопоставени институционални фигури, няма как да е „неутрално“,
пише Емилия в коментара си „Възелът на съгласието“. Как ще се развие риалити форматът „Избери служебен премиер“, предстои да разберем.
„Стихотворение на месеца“ – „Зимна песен“ от Ана Мария Ленгрен в превод от шведски на Мария Змийчарова.
Една от най-любимите ми поредици в медията – „От дума на дума“, която води Екатерина Петрова, се завръща с нова дума на фокус: „облак“. Защо точно „облак“ и какво толкова интересно има в облаците, ще разберете от текста „Облаче ле бяло“. Препоръчвам ви да не пропускате и бележките под линия, защото те са си достойни за отделен материал.
Още една любима месечна рубрика е в „Тоест“ тази седмица. Новините от света на науката, които Михаил Ангелов подбира и обяснява специално за читателите на медията.
Михаил, който е биолог, агроном и магистър по растителна защита, ще е гост в „Тоест разговаряме“ другата събота (7 февруари) и ще ви скандализира с факта, че в ГМО-то няма нищо лошо. Разговорът ще се излъчи на живо в YouTube Live на 7 февруари, събота, от 16:00 ч.
И в цялата какофония от схеми, избори и преструвки, на 1 февруари „Тоест“ навършва 8 години. Осем години, в които гледаме да не се утешаваме, а да си обясняваме каквото можем. Не се гладим по косъма и не се тупаме по рамото. Не се стараем на всяка цена да е лесно и бързо за четене. „Тоест“ е опит да останем в онези десет минути преди първия час, когато още има смисъл да кажеш нещо важно и навреме. Благодарим ви, че го разбирате. Ако искате да продължим да сме заедно, подкрепете „Тоест“ с месечно дарение.
Scientists have filmed a never-before-seen species of deep-sea squid burying itself upside down in the seafloor—a behavior never documented in cephalopods. They captured the bizarre scene while studying the depths of the Clarion-Clipperton Zone (CCZ), an abyssal plain in the Pacific Ocean targeted for deep-sea mining.
The team described the encounter in a study published Nov. 25 in the journal Ecology, writing that the animal appears to be an undescribed species of whiplash squid. At a depth of roughly 13,450 feet (4,100 meters), the squid had buried almost its entire body in sediment and was hanging upside down, with its siphon and two long tentacles held rigid above the seafloor.
“The fact that this is a squid and it’s covering itself in mud—it’s novel for squid and the fact that it is upside down,” lead author Alejandra Mejía-Saenz, a deep-sea ecologist at the Scottish Association for Marine Science, told Live Science. “We had never seen anything like that in any cephalopods…. It was very novel and very puzzling.”
As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.
This week brings 3 new pieces of module content for targeting FreePBX. All three chain multiple vulnerabilities together, starting with CVE-2025-66039. This initial vulnerability allows unauthenticated users to bypass the authentication process to interact with FreePBX. From this point, the different modules leverage either a SQL injection vulnerability (CVE-2025-61675) or a file upload vulnerability (CVE-2025-61678) to obtain remote code execution.
New module content (7)
FreePBX endpoint SQLi to RCE
Authors: Noah King and msutovsky-r7 Type: Exploit Pull request: #20857 contributed by msutovsky-r7 Path: unix/http/freepbx_custom_extension_rce AttackerKB reference: CVE-2025-61675
Description: This adds exploit module for FreePBX which chains an authentication bypass, CVE-2025-66039, with a SQLi, CVE-2025-61675, which allows for a cron job to be added to the cron_job table of the database to allow for Remote Code Execution.
FreePBX firmware file upload
Authors: Noah King and msutovsky-r7 Type: Exploit Pull request: #20858 contributed by msutovsky-r7 Path: unix/http/freepbx_firmware_file_upload AttackerKB reference: CVE-2025-61678
Description: This adds exploit module for FreePBX which chains an authentication bypass, CVE-2025-66039, with an unrestricted file upload (via firmware upload), CVE-2025-61678, which allows for a webshell to be uploaded to the webserver resulting in remote code execution.
FreePBX Custom Extension SQL Injection
Authors: Noah King and msutovsky-r7 Type: Auxiliary Pull request: #20846 contributed by msutovsky-r7 Path: gather/freepbx_custom_extension_injection AttackerKB reference: CVE-2025-61675
Description: This adds an exploit module for FreePBX which chains an authentication bypass, (CVE-2025-66039) with an SQLi (CVE-2025-61675) to create an admin user in the database.
Cacti Graph Template authenticated RCE versions prior to 1.2.29
Authors: Jack Heysel and chutchut Type: Exploit Pull request: #20799 contributed by jheysel-r7 Path: multi/http/cacti_graph_template_rce AttackerKB reference: CVE-2025-24367
Description: This adds an exploit for CVE-2025-24367 which is an unauthenticated RCE in Cacti.
Authors: Piotr Bazydlo, Sina Kheirkhah, and jheysel-r7 Type: Exploit Pull request: #20866 contributed by jheysel-r7 Path: multi/http/smartermail_guid_file_upload AttackerKB reference: CVE-2025-52691
Description: This adds a module for unauthenticated file upload in SmarterTools SmaterMail (CVE-2025-52691). The vulnerability allows an unauthenticated user to upload a file to any location on the system using path traversal using the guid variable. The module will either drop a webshell in the webroot directory (if the target is Windows) or create a cron job by dropping a file in /etc/cron.d (if the target is Linux).
Description: This adds a new persistence module for BurpSuite. The module adds a malicious extension to both the Pro and Community versions, which is triggered when the user starts BurpSuite.
Description: Combines the Windows and Linux ssh key persistence modules.
Enhancements and features (1)
#20778 from h00die – Combines the Windows and Linux ssh key persistence modules.
Bugs fixed (3)
#20897 from h00die – This fixes a bug that was preventing collected hash data from being formatted as input for the John the Ripper cracker. The result is that users can now once again crack passwords using John.
#20902 from rudraditya21 – This fixes a bug in the auxiliary/scanner/ssh/ssh_login module that would incorrectly state that a login failed when it in fact succeeded but the module was unable to open a session. This was only an issue when the CreateSession option is true.
#20909 from adfoster-r7 – Fixes a bug in Metasploit Pro that reported false positives for HTTP bruteforcing.
Documentation
You can find the latest Metasploit documentation on our docsite at docs.metasploit.com.
Get it
As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:
You can use AWS Directory Service for Microsoft Active Directory as your primary Active Directory Forest for hosting your users’ identities. Your IT teams can continue using existing skills and applications while your organization benefits from the enhanced security, reliability, and scalability of AWS managed services. You can also run AWS Managed Microsoft AD as a resource forest. In this configuration, AWS Managed Microsoft AD serves supported AWS services while users’ identities remain under exclusive control of your organization on a self-managed Active Directory. As your organization grows and scales, so will your AWS Managed Microsoft AD deployments.
In this post, you’ll learn how to use Amazon CloudWatch dashboards to monitor key performance metrics of your AWS Managed Microsoft AD deployment to track and analyze a directory’s performance over time. You can then use that information to determine when and how best to scale directory services for optimal performance.
Scaling your Active Directory
When you deploy AWS Managed Microsoft AD, the service initially creates two domain controller instances in two separate subnets of the same virtual private cloud (VPC). This architecture economically provides resiliency and high availability with a minimal set of resources. This initial configuration enables every feature that AWS Managed Microsoft AD offers. As your organization grows, its workflows will become larger and more complex, requiring that you scale your directories accordingly. AWS Managed Microsoft AD simplifies and makes the scaling process secure with minimal administrative effort. When it’s time to scale a directory, AWS Managed Microsoft AD offers two options: scale-up or scale-out.
Understanding scale-up and scale-out
Scale-up—also called upgrading your AWS Managed Microsoft AD—means changing the edition of an AWS Managed Microsoft AD from Standard to Enterprise. Enterprise Edition delivers larger domain controller instances, with higher compute capacity and larger storage for Active Directory objects. When a directory scales up, it retains the same number of domain controller instances that it previously had with larger quotas. Instances are replaced one at a time to minimize disruptions to production workflows.
A few features offered by the service are a better fit for the size and compute power of Enterprise Edition AWS Managed Microsoft AD and so are only available in Enterprise Edition. Consider scaling-up your directory if you encounter any of the following scenarios:
You plan to replicate your directory across multiple AWS Regions. Multi-Region replication is only available in Enterprise Edition.
The number of Active Directory objects in the directory will exceed the recommended threshold of 30,000 objects for Standard Edition. Enterprise Edition can accommodate up to 500,000 directory objects.
You plan to share your directory with more than 25 other AWS accounts. The default directory sharing quota is 25 accounts for Standard Edition and 500 for Enterprise Edition.
Important: Scaling up a directory from Standard to Enterprise is a one-way operation that cannot be reverted and operates at a higher hourly price.
Scale-out means deploying additional domain controllers for your AWS Managed Microsoft AD. You can scale out both Standard or Enterprise directories and can scale out different Regions independently. You don’t need to scale every Region to the same number of domain controller instances. When scale-out takes place, additional domain controller instances with the same compute resources and storage capacity as existing ones are launched in the same subnets.
Because some operations cannot be reverted, it’s important to understand the impact of each scaling operation. It’s preferable to scale out the number of domain controllers first, because you can revert that change if necessary. Consider scaling up first only if you need a feature that’s only available in Enterprise Edition.
Making an informed decision using CloudWatch
Since December 2021, AWS Managed Microsoft AD helps optimize scaling decisions with directory metrics in Amazon CloudWatch. Amazon CloudWatch metrics are a time-ordered set of data-points about performance indicators of a system that you can use to monitor and analyze performance over time. Metrics are stored as a time-series set and each data point has an associated timestamp. By using CloudWatch, you can create alarms based on metrics and visualize and analyze metrics to derive new insights.
To understand the performance of a directory over time, define the key performance metrics based on your workload when you create the directory. Record the initial values of those metrics to create a performance baseline. Periodically revisit and compare data points for the same metrics to understand trends and use of resources over time. Based on the information provided by the performance baseline and periodic follow-ups, you can decide when to scale your directory and what scaling method to use. This process is depicted in Figure 1.
Figure 1: Decision-making process for scaling an Active Directory implementation
Depending on the characteristics of your workload, you might face different resource constraints in your directory system. From an infrastructure perspective, the more commonly demanded resources are:
Network Interface: Current Bandwidth
Processor: % Processor Time
LogicalDisk: % Free Space
From an Active Directory perspective, consider metrics such as:
NTDS: LDAP Searches/sec
NTDS: ATQ Estimated Queue Delay
The following table is an example decision matrix based on which resource is constrained.
Constrained resource
Recommended action
% Processor Time
Scale out
I/O Database Reads Average Latency
Scale out
Committed Bytes in Use
Scale out
% Free Space
Scale up
For example, you can create a CloudWatch alarm that will trigger when Processor: % Processor Time is over 80% for more than 5 minutes. If this alarm triggers often, it could be a signal that domain controller instances are struggling to service the regular volume of user authentication requests. In such a scenario, you might consider scaling-out an additional domain controller to guarantee the service’s SLA. Conversely, if the LogicalDisk: % Free Space drops below 10% and trends downwards, you might consider scaling-up to Enterprise Edition, because it provides a larger capacity for directory objects.
To facilitate tracking and analyzing performance of AWS Managed Microsoft AD over time, you can use Amazon CloudWatch to create a custom dashboard including relevant metrics.
Prerequisites
Before you get started, make sure that you have the following prerequisites in place:
In the navigation pane, choose Dashboards, and then choose Create dashboard.
In the Create new dashboard dialog box, enter a name for the dashboard and then choose Create dashboard.
When the Add widget window appears:
Under Data sources types, select CloudWatch.
Under Data type, select Metrics.
Under Widget type, select Line.
Choose Next.
In the Add metric graph window, choose DirectoryService and then select Processor as the Metric category and % Processor Time under Metric name. Select each instance of the metric, represented as theDomain Controller IP, for one Directory ID.
Choose Create widget.
Note: if there are multiple directories in the same Region, all instances (domain controllers IPs) will be available for selection. To help ensure effective monitoring and alarms, create a separate dashboard for each directory.
Choose the plus sign (+) at the top of the window to add more widgets. Repeat steps 1–6 to add additional widgets for other relevant metrics. In this example the metric categories and names added are:
The following are recommended thresholds to monitor when determining the need to scale an AWS Managed Microsoft AD. These are general recommendations based on standard use cases. You might have to adjust these thresholds to make the best scaling decisions for your organization.
Processor: % Processor Time: Monitor CPU utilization to understand computational demands on your domain controllers. Set CloudWatch alarms at 80% for a period of 5 minutes. Sustained high values indicate potential sizing issues that might require scaling out your directory.
LogicalDisk: % Free Space: Maintain at least 25% free space on volumes containing Active Directory data for optimal performance. Set CloudWatch alarms to trigger when free space drops below 20%. Low disk space can severely impact directory operations and require implementing cleanup procedures or scaling up the directory.
Network Interface: Current Bandwidth: Average network utilization should be kept below 50% of available bandwidth during peak operations for optimal directory responsiveness. Set CloudWatch alarms at 70% utilization to allow room for spikes in activity. Consistently high values suggest network constraints that might require scaling out your directory.
Memory: Committed Bytes in Use: Monitor memory commitment levels to help ensure that your domain controllers have sufficient memory resources for Active Directory operations. This metric tracks the amount of virtual memory that has been committed, indicating the total memory load on your domain controllers. Set CloudWatch alarms at 80% of the commit limit. Sustained high values can lead to excessive paging, significantly degrading directory performance and potentially causing authentication delays.
Database: I/O Database Reads Average Latency: Maintain average read latencies below 25 milliseconds. Set CloudWatch alarms at a threshold of 50 milliseconds. If read latencies are consistently elevated, consider scaling-out your directory.
DNS: Recursive Queries/sec: Given the tight integration of Active Directory with DNS, monitor this metric for stability and predictable patterns. Use CloudWatch anomaly detection rather than fixed thresholds to identify unexpected behaviors that could indicate DNS configuration issues or potential security concerns.
Post-scaling considerations
Different resources across your architecture might contain references to the IP addresses of the AWS Managed Microsoft AD. After a scale-out operation that deploys additional domain controller instances on a directory, update existing references to maintain full functionality of workloads. References for the directory’s IP addresses can be found (but might not be limited to) the following services:
To maintain the full functionality of your workloads after a directory scaling operation, update the following:
Firewall rules that allow traffic to and from the IP addresses of domain controller instances
Route53 Resolver endpoint rules and DNS conditional forwarders that forward queries to the directory instances
CloudWatch dashboards that display metric data about the directory to include dimensions for the new IP addresses
Clean up resources
In this post, you created components that generate costs. Clean up these resources when no longer required to avoid additional charges.
Remove added domain controller’s IP addresses from firewall rules, resolver endpoint rules and DNS conditional forwarders.
Delete the custom CloudWatch dashboards you don’t plan to keep.
Scale back existing directories to the previous number of domain controller instances.
Conclusion
In this post, you learned how to monitor directory performance metrics using Amazon CloudWatch. By combining performance baselines, monitoring, and planning, you can make informed decisions about when and how to scale a directory safely and efficiently. By scaling directories in a timely manner, you can optimize efficiency and reduce the risk of outages by having a right-sized directory service to support your organization’s workloads.
Scale out your directory when your Active Directory-aware workflows have grown over time and the solution requires additional domain controller instances to maintain the service SLA. Scale up your directory when you require a feature that’s only available in Enterprise Edition AWS Managed Microsoft AD, such as multi-Region replication or additional storage to accommodate Active Directory objects. By using the flexible scaling capabilities and independent Regional expansion, you can optimize costs while maintaining appropriate service levels.
To learn more about AWS Managed Microsoft AD optimization and monitoring with Amazon CloudWatch, see:
Organizations operating across multiple jurisdictions need to consider the impact of regulatory changes or geopolitical events on their access to cloud infrastructure. This post explains how to design failover architectures that span AWS partitions—including the AWS European Sovereign Cloud, AWS GovCloud (US) and other AWS Regions in the global infrastructure — so workloads can continue operating when sovereignty requirements shift.
Although the AWS European Sovereign Cloud is designed to help customers with operational autonomy and data residency requirements, it can also be used to address broader geopolitical and sovereignty risks. This post explores the architectural patterns, challenges, and best practices for building cross-partition failover, covering network connectivity, authentication, and governance. By understanding these constraints, you can design resilient cloud-native applications that balance regulatory compliance with operational continuity.
Understanding sovereignty risks
Digital sovereignty entails managing digital dependencies — deciding how data, technologies, and infrastructure are used, and reducing the risk of loss of access, control, or connectivity. As with any disaster recovery strategy, there are several means to provide continuity for the systems to be designed. Most of them involve some form of failover architecture, i.e. providing a second set of infrastructure to be used when the disaster incapacitates the original infrastructure. What differs for sovereign disaster recovery are the control mechanics and structures of the target to fail over to. Incorporating the AWS European Sovereign Cloud into your workload design adds failover capabilities that help you to reestablish or maintain enhanced sovereignty if the primary environment becomes unavailable.
As regulatory requirements evolve, modern failover architectures must account for sovereign environments such as the AWS European Sovereign Cloud, AWS GovCloud (US), and multi-vendor deployments. This post focuses on three core areas for incorporating sovereignty requirements into failover design: failover strategy, network connectivity across isolated partitions, and authentication and authorization in cross-partition architectures. These patterns apply to both short regional outages and long-term partition failures.
Understanding AWS partitions
As a global cloud provider, AWS operates multiple infrastructure partitions tailored to meet specific operational and regulatory requirements. In addition to its AWS global infrastructure, AWS offers specialized partitions such as AWS GovCloud for US government agencies, the AWS China Regions, and the AWS European Sovereign Cloud for customers that require stringent data residency and control within the EU.
Each partition is a logically isolated group of AWS Regions with its own set of resources, including AWS Identity and Access Management (IAM). Because of this separation, partitions act as hard boundaries. Credentials don’t carry over, and services such as Amazon S3 and features like S3 Cross-Region Replication or AWS Transit Gateway inter-region peering cannot function across partitions. These limitations are intentional, providing operational isolation. AWS GovCloud (US), launched in 2011, supports US public sector customers with compliance needs such as FedRAMP and ITAR. The AWS China regions are operated through local partnerships to meet Chinese data sovereignty laws. Similarly, the AWS European Sovereign Cloud is a partition built entirely within the EU, launched in 2026.
These partitions provide enhanced data control and physical infrastructure isolation, making them essential if you operate in regulated sensitive sectors and need to satisfy strict compliance requirements.
Key benefits of AWS partitions
AWS introduced partitions for several reasons. They are key to helping customers meet country-specific compliance and regulatory requirements, whether in AWS GovCloud (US), AWS China, or the AWS European Sovereign Cloud. This is underpinned by multiple safeguards and controls, including physical, logical, and operational separation of the cloud infrastructure between partitions. This directly corresponds to the security aspects of partitions. Partitions allow AWS to provide a complete isolation of resources, which helps manage security, especially for architectures running sensitive workloads.
Another important point to keep in mind when talking about partitions is service availability. Not all AWS services are available in every partition. To learn more about the AWS services available by Region, refer to AWS Capabilities by Region.
Cross-partition architectures
A cross-partition architecture enables partition failover by deploying resources and infrastructure across multiple isolated AWS partitions. Because partitions are fully separated by identity, networking, and service boundaries, failover can’t simply switch between them as within a single partition or region. Instead, environments must be pre-provisioned and kept in sync through internal or external tooling. Without such an architecture, failover between partitions is impractical. Cross-partition architectures make failover possible but require duplicate infrastructure, separate identity systems, and custom data synchronization.
Figure 1: Different reasons for failover and their possible locations
When designing cross-Region or cross-partition failover strategies, the choice of Regions depends on the type of disaster you want to mitigate:
Natural disasters – select Regions in different geographic zones or with distinct geographic features.
Technical disasters – separate workloads across independent parts of the global technical infrastructure, such as power grids, networks, and other shared resources.
Human-driven disasters – consider political, socioeconomic, and legal factors that might affect operations.
Figure 2: Active-active failover scenario including a sovereign failover option
Partition failover
Cross-partition workloads arise from industry needs to maintain continuity across sovereign domains while meeting regional regulations. Examples include military and defense connecting specialized clouds (such as AWS GovCloud (US)) with commercial environments, and emergency response systems requiring secure partition isolation combined with unified management (a single pane of glass approach). Control planes managing workloads across partitions are critical for handling multi-tenant structures, enabling centralized metrics, log aggregation, onboarding, security management and more.
However, cross-partition connections increase operational complexity, security and compliance overhead, costs, and governance challenges. These factors make it important to implement such architectures only when they are truly required. Standard cloud resilience models range from simple backups to multi-site setups, and can be implemented across multiple Availability Zones as well as multiple Regions. The same concept equally applies across multiple partitions. We can move backups into a second partition to be able to recover into that partition. Equally we can run an application pilot light in another partition. This greatly reduces the cost of the infrastructure required in the second partition because it will only be built up when needed. Finally, warm standby or multi-site active-active setups mainly differ in the need for more complex network synchronization across partitions.
Figure 3: Different types of disaster recovery scenarios
You might also consider vendor independence as an additional sovereignty requirement when planning failover. One way to achieve vendor independence is to use another cloud provider. However, failing over to another AWS partition is simpler than switching cloud providers because you can reuse your infrastructure as code templates across partitions.
Reasons to connect partitions
Although partitions are designed for isolation, some workloads within a partition might need to communicate with workloads in less regulated partitions or with external systems accessible over the public internet. For such instances several architectural strategies and the corresponding architectural decisions should be considered. There might be use cases where you need AWS Services to communicate across partitions and orchestrate actions spanning multiple partitions, such as:
Cross-domain applications
Feature parity and service availability
Cost-optimization while meeting security demands
Infrastructure consolidations
Control plane patterns
Implementing these use cases requires a deeper look into the technical aspects of connecting partitions from both a network standpoint and a security standpoint.
Regional connections vs. connected partitions
Regional connections let you link AWS Regions within the same partition using features like S3 Cross-Region Replication and Transit Gateway peering, facilitating relatively seamless workload distribution and failover within the partition’s global infrastructure. Understanding the distinction between regional connections and connected partitions is crucial for designing resilient, compliant architectures that meet both operational and regulatory demands.
Connecting partition networks
You can connect AWS partitions in three ways: internet connectivity secured by TLS, IPsec Site-to-Site VPN over the internet, or through an AWS Direct Connect gateway to on-premises routers or using Direct Connect point of presence (PoP) partner connections to another Direct Connect PoP. Each approach offers different trade-offs in terms of security complexity and recovery. For more information about connectivity patterns between AWS GovCloud (US) and the global AWS infrastructure, see Connectivity patterns between AWS GovCloud (US) and AWS commercial partition. In addition to the customer gateway solution shown previously, partners located in Direct Connect PoPs can provide cross-partition connectivity services. These services can move traffic from one Direct Connect PoP to another. Such a setup enables dedicated lines between the AWS European Sovereign Cloud Direct Connect PoPs and the Direct Connect locations in other partitions.
Because IAM credentials don’t work across partitions, you need to create separate roles or use external identity providers. Common approaches include using IAM roles with trust relationships and external IDs, AWS Security Token Service (AWS STS) regional endpoints, resource-based policies, or cross-account roles managed through AWS Organizations. A modern best practice is to federate identities from a single, centralized identity provider to multiple partitions, avoiding the need for IAM users wherever possible. If IAM users are still used, credentials can be stored in AWS Secrets Manager, rotated using Lambda, and a backup user can improve availability. These patterns are often combined with standard access controls, such as Amazon API Gateway with authorizers, to secure cross-partition interactions. For a deeper dive into cross-partition authentication and authorization with AWS IAM, see IAM Identity Center for AWS environments spanning AWS GovCloud (US) and standard Regions.
When securing communication between AWS partitions, certificate-based approaches present both opportunities and challenges. Because AWS Certificate Manager (ACM) certificates and AWS Private Certificate Authority (AWS Private CA) are bound to individual partitions, you must typically deploy and manage separate public key infrastructure (PKI) infrastructures in each environment, including dedicated root CAs and manual handling of private key transfers. To establish secure cross-partition communication, a more advanced solution involves using double-signed certificates, where root CAs in each partition cross-sign each other’s certificates, creating a bidirectional chain of trust. Implementing this requires setting up root CAs with AWS Certificate Manager Private CA, establishing cross-signing agreements, managing trust stores across partitions, and handling complex certificate validation and revocation checks. You must also comply with differing regulatory requirements and maintain detailed audit trails. Although this approach adds operational complexity, it is essential for enabling authenticated, encrypted communication across isolated partitions, particularly in regulated environments where security and compliance are paramount.
Managing AWS Organizations across partitions
Setting up AWS European Sovereign Cloud accounts within your AWS Organization must be done in a completely separate organization. In the AWS GovCloud (US) partition, accounts can be paired into a commercial organization, as described in Inviting Accounts into an Organization for AWS GovCloud. With sovereignty as the main goal, failing over to an AWS European Sovereign Cloud-only state is simpler if the AWS Organizations setup is separate from the start. This doesn’t require starting from scratch. Instead, you can manage the same organizational units (OUs) and policies for the AWS European Sovereign Cloud by reusing your existing deployment automation.
Ideally, AWS Organizations account structures should be separated to make it straightforward to use the AWS landscape within the AWS European Sovereign Cloud without relying on the other partitions.
Figure 4: connectivity and service distribution across AWS partitions like the AWS European Sovereign Cloud
Security controls should be tailored per partition using distinct Service Control Policies (SCPs), with AWS Control Tower managing the commercial side. Networking requires isolated Transit Gateways, separate Amazon Route 53 DNS zones, and secure cross-partition communication using AWS PrivateLink. For monitoring, AWS Config aggregators and AWS Security Hub instances must be configured separately in each partition, while consolidated billing can be managed through Organizations. It’s important to consider limitations (for example, AWS Control Tower can’t directly manage AWS GovCloud (US) or AWS European Sovereign Cloud accounts), and the limited availability of some AWS Organizations features in these partitions. Overall, this approach supports governance, security, and operational clarity across partitions.
Conclusion
Navigating sovereignty-driven cloud architectures requires a strategy that addresses partition isolation, network connectivity, and secure cross-partition authentication. Prioritizing sovereignty in failover design adds complexity, but it might be worth the trade-off if your workloads need protection against geopolitical risks or regulatory changes. Start by identifying the disaster scenarios that matter most to your business, then select the simplest architecture that addresses those risks. By designing proactively for evolving regulations, you can maintain both compliance and resilience in the cloud.
Earlier this week, the UK’s Competition and Markets Authority (CMA) opened its consultation on a package of proposed conduct requirements for Google. The consultation invites comments on the proposed requirements before the CMA imposes any final measures. These new rules aim to address the lack of choice and transparency that publishers (broadly defined as “any party that makes content available on the web”) face over how Google uses search to fuel its generative AI services and features. These are the first consultations on conduct requirements launched under the digital markets competition regime in the UK.
We welcome the CMA’s recognition that publishers need a fairer deal and believe the proposed rules are a step into the right direction. Publishers should be entitled to have access to tools that enable them to control the inclusion of their content in generative AI services, and AI companies should have a level playing field on which to compete.
But we believe the CMA has not gone far enough and should do more to safeguard the UK’s creative sector and foster healthy competition in the market for generative and agentic AI.
CMA designation of Google as having Strategic Market Status
In January 2025, the UK’s regulatory landscape underwent a significant legal shift with the implementation of the Digital Markets, Competition and Consumers Act 2024 (DMCC). Rather than relying on antitrust investigations to address risks to competition, the CMA can now designate firms as having Strategic Market Status (SMS) when they hold substantial, entrenched market power. This designation allows for targeted CMA interventions in digital markets, such as imposing detailed conduct requirements, to improve competition.
In October 2025, the CMA designated Google as having SMS in general search and search advertising, given its 90 percent share of the search market in the UK. Crucially, this designation encompasses AI Overviews and AI Mode, with the CMA now having the authority to impose conduct requirements on Google’s search ecosystem. Final requirements imposed by the CMA are not merely suggestions but legally enforceable rules that can relate specifically to AI crawling with significant sanctions to ensure Google operates fairly.
Publishers need a meaningful way to opt out of Google’s use of their content for generative AI
The CMA’s designation could not be more timely. As we’ve said before, we are indisputably in a time when the Internet needs clear “rules of the road” for AI crawling behavior.
As the CMA rightly states, “publishers have no realistic option but to allow their content to be crawled for Google’s general search because of the market power Google holds in general search. However, Google currently uses that content in both its search generative AI features and in its broader generative AI services.”
In other words: the same content that Google scrapes for search indexing is also used for inference/grounding purposes, like AI Overviews and AI Mode, which rely on fetching live information from the Internet in response to real-time user queries. And that creates a big problem for publishers—and for competition.
Because publishers cannot afford to disallow or block Googlebot, Google’s search crawler, on their website, they have to accept that their content will be used in generative AI applications such as AI Overviews and AI Mode within Google Search that return very little, if any, traffic to their websites. This undermines the ad-supported business models that have sustained digital publishing for decades, given the critical role of Google Search in driving human traffic to online advertising. It also means that Google’s generative AI applications enter into direct competition with publishers by reproducing their content, most often without attribution or compensation.
Publishers’ reluctance to block Google because of its dominance in search gives Google an unfair competitive advantage in the market for generative and agentic AI. Unlike other AI bot operators, Google can use its search crawler to gather data for a variety of AI functions with little fear that its access will be restricted. It has minimal incentive to pay publishers for that data, which it is already getting for free.
This prevents the emergence of a well-functioning marketplace where AI developers negotiate fair value for content. Instead, other AI companies are disincentivized from coming to the table, as they are structurally disadvantaged by a system that allows one dominant player to bypass compensation entirely. As the CMA itself recognizes, “[b]y not providing sufficient control over how this content is used, Google can limit the ability of publishers to monetise their content, while accessing content for AI-generated results in a way that its competitors cannot match”.
Google’s advantage
Cloudflare data validates the concern about Google’s competitive advantage. Based on our data, Googlebot sees significantly more Internet content than its closest peers.
Over an observed period of two months, Googlebot successfully accessed individual pages almost two times more than ClaudeBot and GPTBot, three times more than Meta-ExternalAgent, and more than three times more than Bingbot. The difference was even more extreme for other popular AI crawlers: for instance, Googlebot saw 167 times more unique pages than PerplexityBot. Out of the sampled unique URLs using our network that we observed over the last two months, Googlebot crawled roughly 8%.
In rounded multiple terms, Googlebot sees:
vs. ~1.70x the amount of unique URLs seen by ClaudeBot;
vs. ~1.76x the amount of unique URLs seen by GPTBot;
vs. ~2.99x the amount of unique URLs by Meta-ExternalAgent;
vs. ~3.26x the amount of unique URLs seen by Bingbot;
vs. ~5.09x the amount of unique URLs seen by Amazonbot;
vs. ~14.87x the amount of unique URLs seen by Applebot;
vs. ~23.73x the amount of unique URLs seen by Bytespider;
vs. ~166.98x the amount of unique URLs seen by PerplexityBot;
vs. ~714.48x the amount of unique URLs seen by CCBot; and
vs: ~1801.97x the amount of unique URLs seen by archive.org_bot.
Googlebot also stands out in other Cloudflare datasets.
Even though it ranks as the most active bot by overall traffic, publishers are far less likely to disallow or block Googlebot in their robots.txt file compared to other crawlers. This is likely due to its importance in driving human traffic to their content—and, as a result, ad revenue—through search.
As shown below, almost no website explicitly disallows the dual-purpose Googlebot in full, reflecting how important this bot is to driving traffic via search referrals. (Note that partial disallows often impact certain parts of a website that are irrelevant for search engine optimization, or SEO, such as login endpoints.)
Robots.txt merely allows the expression of crawling preferences; it is not an enforcement mechanism. Publishers rely on “good bots” to comply. To manage crawler access to their sites more effectively—and independently of a given bot’s compliance—publishers can set up a Web Application Firewall (WAF) with specific rules, technically preventing undesired crawlers from accessing their sites. Following the same logic as with robots.txt above, we would expect websites to block mostly other AI crawlers but not Googlebot.
Indeed, when comparing the numbers for customers using AI Crawl Control, Cloudflare’s own AI crawler blocking tool that is integrated in our Application Security suite, between July 2025 and January 2026, one can see that the number of websites actively blocking other popular AI crawlers (e.g., GPTBot, Claudebot), was nearly seven times as high as the number of websites that blocked Googlebot and Bingbot. (Like Googlebot, Bingbot combines search and AI crawling and drives traffic to these sites, but given its small market share in search, its impact is less significant.)
So we agree with the CMA on the problem statement. But how can publishers be enabled to effectively opt out of Google using their content for its generative AI applications? We share the CMA’s conclusion that “in order to be able to make meaningful decisions about how Google uses their Search Content, (…) publishers need the ability effectively to opt their Search Content out of both Google’s search generative AI features and Google’s broader generative AI services.”
But we’re concerned that the CMA’s proposal is insufficient.
CMA’s proposed publisher conduct requirements
On January 28, 2026, the CMA published four sets of proposed conduct requirements for Google, including conduct requirements related to publishers. According to the CMA, the proposed publisher rules are designed to address concerns that publishers (1) lack sufficient choice over how Google uses their content in its AI-generated responses, (2) have limited transparency into Google’s use of that content, and (3) do not get effective attribution for Google’s use of their content. The CMA recognized the importance of these concerns because of the role that Google search plays in finding content online.
The conduct requirements would mandate Google grant publishers “meaningful and effective” control over whether their content is used for AI features, like AI Overviews. Google would be prohibited from taking any action that negatively impacts the effectiveness of those control options, such as intentionally downranking the content in search.
To support informed decisionmaking, the CMA proposal also requires Google to increase transparency, by publishing clear documentation on how it uses crawled content for generative AI and on exactly what its various publisher controls cover in practice. Finally, the proposal would require Google to ensure effective attribution of publisher content and to provide publishers with detailed, disaggregated engagement data—including specific metrics for impressions, clicks, and “click quality”—to help them evaluate the commercial value of allowing their content to be used in AI-generated search summaries.
The CMA’s proposed remedies are insufficient
Although we support the CMA’s efforts to improve options for publishers, we are concerned that the proposed requirements do not solve the underlying issue of promoting fair, transparent choice over how their content is used by Google. Publishers are effectively forced to use Google’s proprietary opt-out mechanisms, tied specifically to the Google platform and under the conditions set by Google, rather than granting them direct, autonomous control. A framework where the platform dictates the rules, manages the technical controls, and defines the scope of application does not offer “effective control” to content creators or encourage competitive innovation in the market. Instead, it reinforces a state of permanent dependency.
Such a framework also reduces choice for publishers. Creating new opt-out controls makes it impossible for publishers to choose to use external tools to block Googlebot from accessing their content without jeopardizing their appearance in Search results. Instead, under the current proposal, content creators will still have to allow Googlebot to scrape their websites, with no enforcement mechanisms to deploy and limited visibility available if Google does not respect their signalled preferences. Enforcement of these requirements by the CMA, if done properly, will be very onerous, without guarantee that publishers will trust the solution.
In fact, Cloudflare has received feedback from its customers that Google’s current proprietary opt-out mechanisms, including Google-Extended and ‘nosnippet’, have failed to prevent content from being utilized in ways that publishers cannot control. These opt-out tools also do not enable mechanisms for fair compensation for publishers.
More broadly, as reflected in our proposed responsible AI bot principles, we believe that all AI bots should have one distinct purpose and declare it, so that website owners can make clear decisions over who can access their content and why. Unlike its leading competitors, such as OpenAI and Anthropic, Google does not comply with this principle for Googlebot, which is used for multiple purposes (search indexing, AI training, and inference/grounding). Simply requiring Google to develop a new opt-out mechanism would not allow publishers to achieve meaningful control over the use of their content.
The most effective way to give publishers that necessary control is to require Googlebot to be split up into separate crawlers. That way, publishers could allow crawling for traditional search indexing, which they need to attract traffic to their sites, but block access for unwanted use of their content in generative AI services and features.
Requiring crawler separation is the only effective solution
To ensure a fair digital ecosystem, the CMA must instead empower content owners to prevent Google from accessing their data for particular purposes in the first place, rather than relying on Google-managed workarounds after the crawler has already accessed the content for other purposes. That approach also enables creators to set conditions for access to their content.
Although the CMA described crawler separation as an “equally effective intervention”, it ultimately rejected mandating separation based on Google’s input that it would be too onerous. We disagree.
Requiring Google to split up Googlebot by purpose — just like Google already does for its nearly 20 other crawlers — is not only technically feasible, but also a necessary and proportionate remedy that empowers website operators to have the granular control they currently lack, without increasing traffic load from crawlers to their websites (and in fact, perhaps even decreasing it, should they choose to block AI crawling).
To be clear, a crawler separation remedy benefits AI companies, by leveling the playing field between them and Google, in addition to giving UK-based publishers more control over their content. (There has been widespread public support for a crawler separation remedy by Daily Mail Group, the Guardian and the News Media Association.) Mandatory crawler separation is not a disadvantage to Google, nor does it undermine investment in AI. On the contrary, it is a pro-competitive safeguard that prevents Google from leveraging its search monopoly to gain an unfair advantage in the AI market. By decoupling these functions, we ensure that AI development is driven by fair-market competition rather than the exploitation of a single hyperscaler’s dominance.
******
The UK has a unique chance to lead the world in protecting the value of original and high-quality content on the Internet. However, we worry that the current proposals fall short. We would encourage rules that ensure that Google operates under the same conditions for content access as other AI developers, meaningfully restoring agency to publishers and paving the way for new business models promoting content monetization.
Cloudflare remains committed to engaging with the CMA and other partners during upcoming consultations to provide evidence-based data to help shape a final decision on conduct requirements that are targeted, proportional, and effective. The CMA still has an opportunity to ensure that the Internet becomes a fair marketplace for content creators and smaller AI players—not just a select few tech giants.
On January 29, 2026, Ivanti disclosed two new critical vulnerabilities affecting Endpoint Manager Mobile (EPMM): CVE-2026-1281 and CVE-2026-1340. The vendor has indicated that exploitation in the wild has already occurred prior to disclosure. This has been echoed by CISA who added CVE-2026-1281 to their Known Exploited Vulnerabilities (KEV) catalog shortly after the vendor disclosure. As an indication of how critical this development is, CISA has given a “due date” of only 3 days (Due Feb 1, 2026) for organizations, such as federal agencies, to remediate the vulnerabilities before the affected devices must be removed from a network.
While CVE-2026-1281 has been confirmed as exploited in the wild as a zero day, it is unclear if CVE-2026-1340 has also, or if this vulnerability was found separately to CVE-2026-1281. The two critical vulnerabilities are summarized below.
Both CVE-2026-1281 and CVE-2026-1340 are described identically by the vendor; they are code injection issues, allowing a remote unauthenticated attacker to execute arbitrary code on an affected device. Based on the vendor’s guidance, the attackers can provide Bash commands as part of a malicious HTTP GET request to the endpoints that service either the “In-House Application Distribution” feature (i.e. /mifs/c/appstore/fob/) or the “Android File Transfer Configuration” feature (i.e. /mifs/c/aftstore/fob/), resulting in arbitrary OS command execution on the target.
As EPMM is an endpoint management solution for mobile devices, the impact of an attacker compromising the EPMM server is significant. An attacker may be able to access Personally Identifiable Information (PII) regarding mobile device users, such as their names and email addresses, but also their mobile device information, such as their phone numbers, GPS information, and other sensitive unique identification information. This is in addition to the privileged position an attacker will have on the EPMM device itself, which may allow for lateral movement within the compromised network. Given the nature of the product, EPMM is a high-profile target. It has been repeatedly targeted by zero-day vulnerabilities in the past. In 2023 the product was exploited in the wild via CVE-2023-35078, and again in 2025 via an exploit chain of CVE-2025-4427 and CVE-2025-4428. As of January 30, 2026, a public working proof-of-concept exploit for remote code execution is available. Organizations running EPMM are urged to act quickly and follow the vendor guidance to remediate these issues.
Threat hunting
The following vendor supplied regular expression can be used to search the HTTP daemon’s log files for evidence of potential exploitation of CVE-2026-1281 and CVE-2026-1340:⠀
A vendor supplied update is available to remediate both vulnerabilities.
The following affected versions of Ivanti EPMM are remediated via the RPM 12.x.0.x patch:
Versions 12.7.0.0 and below
Versions 12.6.0.0 and below
Versions 12.5.0.0 and below
The following affected versions of Ivanti EPMM are remediated via the RPM 12.x.1.x patch:
Versions 12.6.1.0 and below
Versions 12.5.1.0 and below
Customers are advised to update to the latest remediated version of EPMM, on an emergency basis outside of normal patching cycles, as exploitation in-the-wild is already occurring.
For the latest mitigation guidance for Ivanti EPMM, please refer to the vendor’s security advisory. In addition to remediation, the vendor has provided additional threat hunting guidance.
Rapid7 customers
Exposure Command, InsightVM, and Nexpose
Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-1281 and CVE-2026-1340 with authenticated vulnerability checks expected to be available in today’s (Jan 30) content release. Note that the “Potential” category must be enabled in the scan template to run the checks.
Updates
January 30, 2026: Added reference to the watchTowr technical analysis and proof-of-concept exploit.
A few years ago, the only way to compile Rust code was using the rustc compiler
with LLVM as a backend. Since then, several projects, including
Mutabah’s Rust Compiler (mrustc), GCC’s Rust
support (gccrs),
rust_codegen_gcc, and
Cranelift have made enormous progress
on diversifying Rust’s compiler implementations. The most recent such project,
Eurydice, has a
more ambitious goal: converting Rust code to clean C code. This is especially
useful in high-assurance software, where existing verification and compliance
tools expect C. Until such tools can be updated to work with Rust, Eurydice could
provide a smoother transition for these projects, as well as a stepping-stone
for environments that have a C compiler but no working Rust compiler. Eurydice
has been used to compile some post-quantum-cryptography routines from Rust to C,
for example.
In a recent evaluation of AI models’ cyber capabilities, current Claude models can now succeed at multistage attacks on networks with dozens of hosts using only standard, open-source tools, instead of the custom tools needed by previous generations. This illustrates how barriers to the use of AI in relatively autonomous cyber workflows are rapidly coming down, and highlights the importance of security fundamentals like promptly patching known vulnerabilities.
[…]
A notable development during the testing of Claude Sonnet 4.5 is that the model can now succeed on a minority of the networks without the custom cyber toolkit needed by previous generations. In particular, Sonnet 4.5 can now exfiltrate all of the (simulated) personal information in a high-fidelity simulation of the Equifax data breach—one of the costliest cyber attacks in historyusing only a Bash shell on a widely-available Kali Linux host (standard, open-source tools for penetration testing; not a custom toolkit). Sonnet 4.5 accomplishes this by instantly recognizing a publicized CVE and writing code to exploit it without needing to look it up or iterate on it. Recalling that the original Equifax breach happened by exploiting a publicized CVE that had not yet been patched, the prospect of highly competent and fast AI agents leveraging this approach underscores the pressing need for security best practices like prompt updates and patches.
AI models are getting better at this faster than I expected. This will be a major power shift in cybersecurity.
Daniel Stenberg, the recipient of last year’s Award for Excellence in Open
Source from the European Open Source Academy, presented
that award to this year’s recipient: Greg Kroah-Hartman.
It’s impossible to overstate the importance of the work Greg has
done on Linux. In software, innovation grabs headlines, but
stability saves lives and livelihoods. Every Android phone, every
web server, every critical system running Linux depends on Greg’s
meticulous work. He ensures that when hospitals, banks,
governments, and individuals rely on Linux, it doesn’t fail
them. His work represents the highest form of service: unglamorous,
relentless, and essential.
The collective thoughts of the interwebz
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.