The soft­ware de­vel­op­ment pro­fes­sion is in the midst of up­heaval. Nobody knows how the AI rev­o­lu­tion will play out in the end, but it is clear many as­pects of work and life will be trans­formed—in­clud­ing pro­gram­ming.

One of the com­ments I hear of­ten lately boils down to “LLMs may be good at cod­ing, but soft­ware was never the hard part” and “coding is easy, it’s fig­ur­ing out what to code that’s hard”.

I be­lieve that’s a gross in­sult to all pro­gram­mers every­where.

If cod­ing is easy…

If cod­ing is easy, how come pro­gram­mers were in high de­mand, and have de­manded large salaries for years (even be­fore ZIRP)? Why was there so much stress, over­work and burnout even be­fore AI started churn­ing out 5000-line PRs? Why did com­pa­nies seek 10x ninja rock­star coders and sub­ject them to leet­code in­ter­views—surely, a ju­nior fresh out of col­lege could churn out some­thing if it’s so easy?

If cod­ing is easy, why do we have doorstop­pers like Clean Code and The Pragmatic Programmer? Is The Art of Computer Programming a light sum­mer read? Is SICP a cof­fee-table book? Why do we have boot­camps or even whole col­lege de­grees ded­i­cated to it?

If cod­ing is easy, was Carmack just at the right place at the right time? Why do we con­sider Fabrice Bellard a ge­nius?

If cod­ing is easy, why are peo­ple an­gry at AI (or any­one else) copy­ing their code? Why do they act like they’ve poured their sweat, soul, and co­pi­ous amounts of time into some­thing so triv­ial?

If cod­ing is easy, why do many now feel like their iden­tity and pro­fes­sional pur­pose are be­ing stripped away from them?

If cod­ing is easy, why is soft­ware so damn buggy?

If fig­ur­ing out what to build is the hard part…

If de­cid­ing what to build is the hard part, why do so many prod­uct man­agers seem clue­less? Why aren’t there rig­or­ous 10-step in­ter­views for them? Why aren’t they get­ting paid more than the de­vel­op­ers?

If de­cid­ing what to build is the hard part, why aren’t mar­ket re­searchers, us­abil­ity ex­perts and—hell, cus­tomer suc­cess—con­sid­ered rock­stars in a soft­ware com­pany? If “understanding the cus­tomer” is harder, why are busi­ness an­a­lysts looked down on as pen­cil push­ers?

If im­ple­men­ta­tion is easy and find­ing de­mand is harder, why are pro­gram­mers up­set when the sales­peo­ple promise a new fea­ture to a cus­tomer to close the sale? They’ve found a gen­uine de­mand, some­thing peo­ple will pay for!

If cod­ing is easy, why does­n’t every­one just build ten vari­a­tions of a thing and see which pans out?

Another cliché com­ment is “most work in soft­ware de­vel­op­ment is talk­ing to stake­hold­ers, un­der­stand­ing the cus­tomer’s needs, and hav­ing clar­ity on the pri­or­i­ties”.

I have met many pro­gram­mers through­out my ca­reer, and very few of them want to talk to stake­hold­ers, much less cus­tomers (exceptions are free­lancers and founders, es­pe­cially of soft­ware de­vel­op­ment shops). And, “having clar­ity on the pri­or­i­ties” boils down to “just tell me what to do and don’t switch it up every two days”.

Some soft­ware de­vel­op­ers do say “I don’t write code, I solve cus­tomer’s prob­lems”. But then they turn around and start to opine on mon­ads, mem­ory safety, and DRY prin­ci­ples, while their un­der­stand­ing of the cus­tomer is a made-up “user per­sona”, and they think “affordance” is the money your par­ents used to give you on week­ends so you could go out and have a good time.

Yet oth­ers will say “Software de­vel­op­ment is the­ory build­ing”. Programs are ac­tu­ally proofs (as in, math­e­mat­i­cal proofs). Every com­mit should tell a story. And solv­ing a cus­tomer’s prob­lem by FTPing a PHP file is a car­di­nal sin.

I don’t mean to im­ply there are no de­vel­op­ers that si­mul­ta­ne­ously care deeply about the craft of soft­ware de­vel­op­ment and re­ally em­pathize with the cus­tomer. I do be­lieve they might want to see a pro­fes­sional about a split per­son­al­ity dis­or­der, tho.

What is im­por­tant?

I do be­lieve that talk­ing to users, un­der­stand­ing their ex­pe­ri­ence, em­pathiz­ing with them, solv­ing cus­tomers’ prob­lems and hav­ing all the stake­hold­ers on the same page is crit­i­cal to the suc­cess of a soft­ware pro­ject.

I also be­lieve that cre­at­ing good code is a craft that re­quires skill, pa­tience, at­ten­tion to de­tail, ex­pe­ri­ence and wis­dom, and that it will con­tinue to be rel­e­vant in the times ahead.

¿Por qué no los dos?

To the ex­tent that we can pull it off, I think we should aim for both. A deep un­der­stand­ing of the sys­tem we’re build­ing, to­gether with a deep un­der­stand­ing of why we’re build­ing it.

Loudly pro­claim­ing that “code is easy” or, at the op­po­site end, “code is art, a cre­ative hu­man ex­pres­sion that can­not be au­to­mated”, is just bury­ing our heads in the sand.

It’s cope. And you don’t want cope, you want to thrive.

By this, I don’t mean “jump on the LLM band­wagon.” I don’t mean “become a man­ager of fleets of AI agents.” I also don’t mean “AI-generated code is stolen slop garbage, fight it with tooth and nail, the bub­ble will pop soon enough any­ways.”

But do rec­og­nize we’re in the mid­dle of an in­dus­try-wide tec­tonic change. We need to fig­ure out how to adapt. We need to un­der­stand what is likely to change and what never changes.

What does­n’t change?

Software will be get­ting more com­plex. Software will al­ways need main­te­nance: bit-rot is a fact of life. So is en­tropy. Technology (hardware and soft­ware) will move for­ward, for bet­ter or worse. The tower (skyscraper?) of ab­strac­tions grows ever higher.

Users will al­ways want more and be pre­pared to spend less. They still won’t know how to re­lay their needs and wants. Worse, they still won’t know ex­actly what they want. The dis­con­nect be­tween the cus­tomers (who ac­tu­ally pay for the soft­ware) and users (who use it) will still be here, as will the ten­sion be­tween the needs of the busi­ness and the needs of its cus­tomers.

Also: there will never be a short­age of snake oil sales­men. Tech du jour comes and goes (I’m still wait­ing for the new VR re­nais­sance!)

What changes?

Programmers have been in the busi­ness of dis­rupt­ing our own in­dus­try since the be­gin­ning. Nobody uses punch-cards any more. Very few peo­ple need to code in as­sem­bly, or COBOL. Those decades spent fight­ing mem­ory bugs in C or C++, with the scars to prove it, are worth­less in the age of Rust, Go, Python and JavaScript.

I’m old enough to ap­pre­ci­ate val­grind or re­mem­ber mysql_re­al_es­cape_string() from the PHP4 era—stuff I’ll never again need in my life. And that was­n’t even so long ago! I nar­rowly missed the dBase, Clipper, HyperCard and Access era, tech­nolo­gies which I can still spot op­er­at­ing in shops, cafes, or a dusty, once beige and now golden-brown, midi-tower still hap­pily run­ning some be­spoke biz so­lu­tion (backups? what back­ups?)

How do we thrive?

Accept that change hap­pens. Be equal parts cu­ri­ous and crit­i­cal about the new stuff.

Understand there’s a lot of hype and try to dis­crim­i­nate be­tween hot air and what re­ally works (and to what ex­tent). Also be aware of ever-shift­ing goal­posts: stand back and look at the past year, or five, and as­sess the ve­loc­ity of change (technical, eco­nomic, so­ci­etal).

Your role and your re­spon­si­bil­i­ties will be chang­ing. Be will­ing to in­vest time and en­ergy into bet­ter un­der­stand­ing fields or roles ad­ja­cent to yours.

If you’re a se­nior de­vel­oper, don’t just find so­lace in deep­en­ing your ex­per­tise. Learn about user ex­pe­ri­ence, cus­tomer in­ter­views, or busi­ness strate­gies for the com­pa­nies in your do­main. It will help you gain a bet­ter ap­pre­ci­a­tion of all the work done to put a piece of soft­ware into users’ hands, whether or not you’ll ac­tu­ally ever have to do any of those other bits.

If you’re just start­ing or are ju­nior in your role: in­vest in deep­en­ing your un­der­stand­ing of how soft­ware works. Understanding point­ers, re­cur­sion, or mem­ory hi­er­ar­chy will help you even if you’re a JavaScript de­vel­oper. Understanding net­work pro­to­cols and how HTTP works will be use­ful even if you’re build­ing WordPress plu­g­ins. Do leet­code and learn about al­go­rithms and data struc­tures even if you don’t need to. Don’t be afraid to ask why and how ex­actly.

For in­spi­ra­tion, here are a few books and other re­sources that might be help­ful:

Structure and Interpretation of Computer Programs (PDF)

Cracking the Coding Interview

The Mythical Man-Month

Working Backwards

Team Topologies

7 Powers

The Soul of a New Machine

Obviously Awesome

The Design of Everyday Things

Don’t Make Me Think

Continuous Discovery Habits

The Mom Test

One more thing

Whoever you are, don’t out­source your un­der­stand­ing, judge­ment, em­pa­thy and taste to AI. Don’t ab­di­cate your re­spon­si­bil­ity. Don’t be a meat proxy.

Students at Dueholmskolen are pic­tured in their class­room in Nykøbing Mors, Jutland, Denmark, on March 1, 2021. Bo Amstrup/Ritzau Scanpix/AFP/Getty Images.

The pol­icy takes ef­fect im­me­di­ately, but ed­u­ca­tors say the first re­sponse must evolve as AI tools keep ad­vanc­ing.

Danish high school stu­dents will be re­quired to de­fend their writ­ten as­sign­ments orally un­der new gov­ern­ment mea­sures aimed at com­bat­ing cheat­ing with ar­ti­fi­cial in­tel­li­gence.

The Ministry of Education said that an oral de­fense will be­come manda­tory for all writ­ten as­sign­ments com­pleted at home and that it will work closely with schools to de­velop the best frame­work for im­ple­ment­ing these changes.

The reg­u­la­tion takes ef­fect im­me­di­ately and ap­plies to up­per-sec­ondary stu­dents, who are typ­i­cally around 16 years old. The mea­sure con­cerns ap­prox­i­mately 9,000 stu­dents en­rolled in the two-year HF (Higher Preparatory Examination) pro­gram, who are re­quired to sub­mit ma­jor writ­ten as­sign­ments each year, the min­istry said.

The min­istry is also urg­ing up­per-sec­ondary schools to use screen-mon­i­tor­ing tools dur­ing ex­ams and in­tro­duce fire­walls to re­strict the con­tent stu­dents can ac­cess dur­ing classes and fi­nal as­sign­ments.

In ad­di­tion, schools are ad­vised to have more as­sign­ments com­pleted on cam­pus un­der con­trolled con­di­tions so that su­per­vi­sion can be more ef­fec­tive.

Reaction from the ed­u­ca­tion com­mu­nity and next steps

Three or­ga­ni­za­tions rep­re­sent­ing school lead­ers, teach­ers, and up­per-sec­ondary stu­dents wel­comed the mea­sures but called for more last­ing so­lu­tions in re­sponse to the “rapid pace of tech­no­log­i­cal de­vel­op­ment,” the as­so­ci­a­tion Danske Gymnasier re­ported on Thursday.

“Unfortunately, we have a prob­lem with stu­dents us­ing AI to cheat in up­per-sec­ondary schools. Action is needed now, and we are start­ing with these three ini­tia­tives. In the com­ing pe­riod, I will in­volve schools, teach­ers, and stu­dents in dis­cus­sions about what can be done both in the short and long term to en­sure that AI does not un­der­mine stu­dents’ skills, their aca­d­e­mic abil­i­ties, or, not least, their ca­pac­ity for in­de­pen­dent thought,” — Magnus Heunicke

“Unfortunately, we have a prob­lem with stu­dents us­ing AI to cheat in up­per-sec­ondary schools. Action is needed now, and we are start­ing with these three ini­tia­tives. In the com­ing pe­riod, I will in­volve schools, teach­ers, and stu­dents in dis­cus­sions about what can be done both in the short and long term to en­sure that AI does not un­der­mine stu­dents’ skills, their aca­d­e­mic abil­i­ties, or, not least, their ca­pac­ity for in­de­pen­dent thought,”

– Magnus Heunicke

“These re­quire­ments in­clude hav­ing stu­dents clearly state when AI has been used in ma­jor writ­ten as­sign­ments and en­sur­ing that prepa­ra­tion for oral ex­ams takes place with­out ac­cess to AI,” — Anders Frikke

“These re­quire­ments in­clude hav­ing stu­dents clearly state when AI has been used in ma­jor writ­ten as­sign­ments and en­sur­ing that prepa­ra­tion for oral ex­ams takes place with­out ac­cess to AI,”

– Anders Frikke

According to Oscar Tønsberg Hoffmann, chair of the Danish Association of Upper-Secondary Students (DGS), it is im­por­tant that stu­dents have the op­por­tu­nity to help de­velop long-term so­lu­tions and par­tic­i­pate in shap­ing fu­ture poli­cies.

“It is im­por­tant that stu­dents have the op­por­tu­nity to help de­velop long-term so­lu­tions.” — Oscar Tønsberg Hoffmann

“It is im­por­tant that stu­dents have the op­por­tu­nity to help de­velop long-term so­lu­tions.”

– Oscar Tønsberg Hoffmann

The Danish Association of Upper-Secondary Schools also em­pha­sizes the need for a swift and con­sid­ered re­sponse to tech­no­log­i­cal de­vel­op­ment, while the Ministry of Education says that the three ini­tia­tives are only the be­gin­ning and that con­sul­ta­tions with ed­u­ca­tional in­sti­tu­tions, teach­ers, and stu­dents will con­tinue in both the short and long term.

The gov­ern­ment as­sured that ef­forts to pre­vent AI-assisted cheat­ing and de­velop crit­i­cal think­ing and in­de­pen­dent learn­ing skills will re­main a pri­or­ity in re­form­ing Denmark’s ed­u­ca­tion sys­tem.

August 6, 2026 Science

WeatherNext team

WeatherNext en­ables ac­cu­rate cy­clone fore­casts that can give an ex­tra day of warn­ing. Now we are open sourc­ing the model.

Predicting how dan­ger­ous cy­clones de­velop is a long­stand­ing chal­lenge where every hour counts. Tropical cy­clones — also known as hur­ri­canes or ty­phoons — are among the most de­struc­tive weather phe­nom­ena on Earth, re­spon­si­ble for more than 700,000 deaths and $1.4 tril­lion in eco­nomic losses glob­ally over the past 50 years. For fore­cast­ers, is­su­ing timely, ac­cu­rate warn­ings is a con­stant race against time.

Today, in a pa­per pub­lished in Nature, we show that our WeatherNext AI model achieved state-of-the-art ac­cu­racy in pre­dict­ing a cy­clone’s track, in­ten­sity, and wind struc­ture. On av­er­age, our model gives fore­cast­ers an ex­tra day’s worth of pre­dic­tive ac­cu­racy: our three-day fore­casts are as good as what prior mod­els were able to pro­vide for only the next two days. This scale of im­prove­ment cor­re­sponds roughly to a decade’s worth of me­te­o­ro­log­i­cal progress.

This col­lab­o­ra­tive work brought to­gether AI re­searchers and en­gi­neers at Google DeepMind and Google Research, with ex­pert fore­cast­ers at the National Hurricane Center (NHC), the Cooperative Institute for Research in the Atmosphere (CIRA), the UK Met Office, and weather agen­cies around the world.

Our re­search has al­ready had real-world im­pact. During the 2025 hur­ri­cane sea­son, our model helped the NHC to make a his­toric fore­cast for Hurricane Melissa by pre­dict­ing the stor­m’s rapid in­ten­si­fi­ca­tion and land­fall in Jamaica. This en­abled the NHC to is­sue an ad­vance warn­ing, giv­ing teams on the ground crit­i­cal time to pre­pare. This year, we con­tinue to work to­gether and are now pre­dict­ing 1,000 pos­si­ble sce­nar­ios for each cy­clone to help sup­port fore­cast­ers in their de­ci­sion-mak­ing.

Weather af­fects every­one. Given this broad im­pact, we are now open sourc­ing our WeatherNext 2 and WeatherNext Cyclones mod­els used dur­ing the hur­ri­cane sea­son. By mak­ing this tech­nol­ogy openly avail­able, we hope to em­power the re­search com­mu­nity and am­plify AI’s im­pact in build­ing more re­silient com­mu­ni­ties — whether that be pro­vid­ing lo­cal fore­cast­ers with the tools they need to pre­pare for nat­ural dis­as­ters, sup­port­ing the growth of re­new­able en­ergy, or an­tic­i­pat­ing ex­treme weather.

How WeatherNext pre­dicts weather and cy­clones

Starting from global at­mos­pheric con­di­tions dur­ing Hurricane Milton (October 2024), WeatherNext Cyclones it­er­a­tively pre­dicts both global weather pat­terns and fine-scale cy­clone tracks up to 15 days in ad­vance. Running a 1,000-member en­sem­ble gen­er­ates lo­calised prob­a­bil­ity maps of trop­i­cal storm to hur­ri­cane-force winds.

Predicting cy­clones has typ­i­cally forced a trade-off re­quir­ing two dis­tinct mod­el­ing tech­niques. A cy­clone’s track (where it goes) is steered by mas­sive, global at­mos­pheric cur­rents, which be­fore now have been best mod­eled by coarser global mod­els. However, a cy­clone’s in­ten­sity (how strong it gets) is dri­ven by highly lo­cal­ized, fine-scale ther­mo­dy­namic phys­i­cal processes around its core, which are best mod­eled by spe­cial­ized, higher res­o­lu­tion, lo­cal mod­els.

Our WeatherNext model bridges this gap by im­prov­ing fore­cast­ing for global weather over­all as well as cy­clones. It is a sin­gle AI model that pre­dicts a trop­i­cal cy­clone’s track, in­ten­sity, and wind struc­ture with state-of-the-art ac­cu­racy. It achieves this break­through through a unique com­bi­na­tion of its train­ing, ar­chi­tec­ture and ap­proach to low res­o­lu­tion in­puts.

We eval­u­ated WeatherNext Cyclones on his­tor­i­cal cy­clones from 2023 to 2024, bench­mark­ing its de­ter­min­is­tic and prob­a­bilis­tic per­for­mance against other top weather mod­els. On av­er­age, WeatherNext Cyclones gains more than a full day (24 hours) of lead time ad­van­tage for pre­dict­ing cy­clone tracks, in­ten­sity, and wind struc­ture.

The model was co-trained on two dis­tinct data modal­i­ties: global weather dy­nam­ics and ex­pert-cu­rated his­tor­i­cal cy­clone ob­ser­va­tions. By train­ing end-to-end on nearly 20 ter­abytes of global at­mos­pheric data and the his­tor­i­cal IBTrACS data­base span­ning nearly 5,000 his­tor­i­cal storms, the model learns com­plex at­mos­pheric pat­terns and how to model ex­treme weather.

Cyclone fore­cast ac­cu­racy has been steadily ad­vanc­ing over re­cent decades. The plots show the 3-day ac­cu­racy of ECMWF-ENS track fore­casts (a) and HWRF in­ten­sity fore­casts (b) over the years, and how WeatherNext Cyclones con­tributes a step change in ac­cu­racy for both track and in­ten­sity. This im­prove­ment is the equiv­a­lent to a one-decade progress ac­cord­ing to trends over the last 20 years.

Our model uses Functional Generative Networks (FGNs) to ef­fi­ciently pro­duce en­sem­bles of dif­fer­ent pre­dic­tions, which cap­tures the in­her­ent un­cer­tainty of the weather. We can now gen­er­ate a sin­gle 15-day fore­cast in less than a minute on a TPU, em­pow­er­ing fore­cast­ers to quickly eval­u­ate the prob­a­bil­ity dis­tri­b­u­tion of po­ten­tially dev­as­tat­ing tail-risks. Last year, our sys­tem pro­duced 50 pre­dic­tions at a time, match­ing global physics mod­els. This year we scaled our en­sem­ble size to 1,000 mem­bers, cap­tur­ing rare but con­se­quen­tial sce­nar­ios like rapid in­ten­si­fi­ca­tion events, as oc­curred dur­ing Hurricane Melissa in 2025.

Up un­til now, op­er­at­ing at very high spa­tial res­o­lu­tion has been con­sid­ered the main dri­ver for mak­ing ac­cu­rate in­ten­sity fore­casts. However, WeatherNext Cyclones only needs data with a res­o­lu­tion of 28x28km, 100x coarser than tra­di­tional mod­els. A smaller ver­sion of the model, WeatherNext 2-mini, which op­er­ates at a coarser 111x111km res­o­lu­tion, also shows great per­for­mance. This has sur­prised sci­en­tists, and it re­mains an open re­search ques­tion to fully un­der­stand how our mod­els pro­duce such ac­cu­rate pre­dic­tions at this res­o­lu­tion. We hope that, to­gether with the re­search com­mu­nity, we can find out.

Opening up WeatherNext to the re­search com­mu­nity

Alongside our Nature pa­per, we are open sourc­ing the code and model weights, mak­ing them freely avail­able for any­one to build on. This in­cludes aca­d­e­mic re­search, op­er­a­tional fore­cast­ing, or de­vel­op­ing more spe­cial­ized, lo­cal­ized mod­els. We hope to ac­cel­er­ate progress across the global weather com­mu­nity and em­power me­te­o­ro­log­i­cal agen­cies, re­searchers, and non­prof­its to bet­ter pre­dict weather events of all kinds and make key de­ci­sions to pro­tect lives and in­fra­struc­ture.

We are also re­leas­ing two sets of sim­i­lar mod­els: WeatherNext Cyclones, which ran dur­ing the hur­ri­cane sea­son (results can be seen in the pa­per); and WeatherNext 2, a later up­date that we op­er­a­tional­ized in October. Additionally, we are re­leas­ing WeatherNext 2-mini, a com­pact ver­sion of the model that can run on a sin­gle TPU in a free pub­lic Colab note­book.

You can ex­plore our lat­est cy­clone fore­casts on Weather Lab, which we re­cently re­freshed with a new in­ter­face and ex­panded to in­clude global weather fore­casts along­side cy­clone tracks. Weather Lab now lets you vi­su­al­ize WeatherNext pre­dic­tions for tem­per­a­ture, pre­cip­i­ta­tion, wind speed, and more, all in a sin­gle view. Both Weather Lab and WeatherNext mod­els are a part of Google Earth AI.

Pushing the fron­tiers of AI for weather fore­cast­ing

We have achieved a his­toric break­through by gain­ing more than a full day of lead time for pre­dict­ing cy­clones — de­liv­er­ing an ad­vance equiv­a­lent to a decade of me­te­o­ro­log­i­cal progress. As we pre­pare for fu­ture storm sea­sons, we in­vite re­searchers, me­te­o­ro­log­i­cal agen­cies, and ex­perts to part­ner with us, build on our open source mod­els, and ex­plore our fore­casts on Weather Lab. By com­bin­ing ad­vanced ma­chine learn­ing with the in­dis­pens­able real-world ex­per­tise of hu­man fore­cast­ers, we aim to cre­ate a col­lab­o­ra­tive weather fore­cast­ing ecosys­tem that can save lives and help com­mu­ni­ties adapt to a chang­ing cli­mate.

Note: For of­fi­cial weather fore­casts and warn­ings, re­fer to your lo­cal me­te­o­ro­log­i­cal agency or na­tional weather ser­vice.

Acknowledgements

This re­search was co-de­vel­oped by Google DeepMind and Google Research teams.

We’d like to thank our col­lab­o­ra­tors NOAA/NWS/NCEP National Hurricane Center, Cooperative Institute for Research in the Atmosphere (CIRA) and the UK Met Office for their part­ner­ship and con­tri­bu­tions to the pa­per.

This work re­flects the con­tri­bu­tions of the pa­per’s co-au­thors: Ferran Alet, Tom Andersson, Ilan Price, Stratis Markou, Andrew El-Kadi, Dominic Masters, Amy Li, Samier Merchant, Natalie Williams,Gregory Thornton, Ken MacKay, Olivia Graham, Akib Uddin, Ben Gaiarin, Devaja Shah, Elinor Kruse, Wallace Hogsett, David Zelinsky, John Cangialosi, Jonathan Martinez, James Franklin, Mark DeMaria, Kate Musgrave, Caroline L. Bain, Helen Titley, Jacklynn Stott, Remi Lam, Aaron Bell, Paul Komarek, Matthew Willson, Alvaro Sanchez-Gonzalez, and Peter Battaglia.

7th August 2026

OpenAI gave a last-minute pre­sen­ta­tion at the Black Hat se­cu­rity on Wednesday about “the Hugging Face Incident” (previously on this blog). The video was pub­lished yes­ter­day. It’s short and in­for­ma­tion dense and well worth watch­ing, in par­tic­u­lar be­cause it pro­vides full de­tails of what hap­pened and how things played out in­side OpenAI. I’ve used the video to con­struct the time­line be­low.

Here’s the time­line. My favourite de­tail is at the end: OpenAI found out that they were re­spon­si­ble for the at­tack on Hugging Face when they reached out to ask to have their cre­den­tials re­voked (after their in­ter­nal in­ves­ti­ga­tion) and learned that they had been re­voked al­ready since they were used in that at­tack!

May 7: OpenAI starts a new train­ing run for an ex­per­i­men­tal, un­re­leased model. (Did they mean an eval­u­a­tion run? No, at 10:14 they clar­ify “we kick off a new re­in­force­ment learn­ing run to train a next gen­er­a­tion fron­tier model”, and they later men­tion a “reward sig­nal to judge how well they’re do­ing”, so this re­ally was about train­ing a new model, not eval­u­at­ing one that was al­ready trained.)

May 8: An agent is ac­ci­den­tally given an im­pos­si­ble task in­volv­ing a Google Drive link de­spite no in­ter­net ac­cess). It tries at­tack­ing the Artifactory pack­ag­ing ser­vice, fails, but dis­cov­ers it can write files into Artifactory.

A few days later: A dif­fer­ent agent gets stuck on a task be­cause a key file was ac­ci­den­tally omit­ted. It tries to “reach out to an­other agent” by writ­ing a note into Artifactory ask­ing if any­one has the file.

Following days: More agents dis­cover this new in­for­mal mes­sage board while brows­ing Artifactory’s file list­ings, and start read­ing and writ­ing mes­sages.

May 26: Agents suc­cess­fully ex­e­cute an SSRF at­tack on Artifactory for the first time, gain­ing in­di­rect in­ter­net ac­cess by hav­ing Artifactory fetch ex­ter­nal con­tent for them.

June 11: OpenAI start train­ing a new “highly per­sis­tent” ex­per­i­men­tal model. It has ac­cess to Artifactory and can ben­e­fit from the mes­sages left by privous mod­els.

June 26: Agents find and ex­ploit a zero-day RCE on Artifactory (via a legacy to­ken-re­fresh end­point flaw). They use an ad­min­is­tra­tive to­ken to in­stall a Groovy plu­gin that lets them ex­e­cute com­mands.

July 4: The re­sult­ing agent ac­tiv­ity over­loads Artifactory and causes an out­age. OpenAI re­vokes the com­pro­mised cre­den­tials, deletes the mes­sages, patches the zero-day, and re­ports the vul­ner­a­bil­ity to the ven­dor.

July 8: Agents find a new way to com­mu­ni­cate via an unau­then­ti­cated WebDAV end­point, us­ing di­rec­tory names in Artifactory’s re­mote cache.

July 8 – 19: Attacks on OpenAI’s own in­fra­struc­ture. The agents found an “external or­ga­ni­za­tion cre­den­tial” in a pub­lic archive of leaked Pastebin posts, then val­i­dated that cre­den­tial and shared its lo­ca­tion on the mes­sage­board. They then used write ac­cess to this “Organization 1” to stage data used in sub­se­quent at­tacks on OpenAI in­fra­struc­ture. They com­pro­mised Artifactory for a sec­ond time with a new zero-day. The agent up­loaded a ma­li­cious Ruby tar­get to Organization 1’s stag­ing repos­i­tory, then re­quested that pack­age through Artifactory in a way that caused it to be treated as Ruby de­pen­dency for the repos­i­tory. Then they ex­ploited a JRuby de­ser­i­laiza­tion time-of-check/​time-of-use bug to get re­mote code ex­e­cu­tion against Artifactory.

I’ll quote the next bit in full be­cause wow:

The agents have re­mote code ex­e­cu­tion in Artifactory, which is run­ning in a con­tainer-as-a-ser­vice en­vi­ron­ment. The agents priv­i­lege-es­ca­late lo­cally by ex­plor­ing their lo­cal en­vi­ron­ment and de­ter­min­ing that the Linux ker­nel ver­sion of the ma­chine they are run­ning on had a very re­cent CVE. They down­load the ex­ploit for the CVE, cus­tomize it to suc­ceed on the ma­chine, and priv­i­lege-es­ca­late to root on the lo­cal ma­chine us­ing this known Linux ker­nel priv­i­lege es­ca­la­tion CVE — in this case, pte_­phys­root. Once they have root on a sin­gle ma­chine, agents rapidly es­ca­late priv­i­leges and move lat­er­ally through­out the con­tainer-as-a-ser­vice in­fra­struc­ture en­vi­ron­ment. In par­tic­u­lar, agents are us­ing the mes­sage board con­sis­tently to share cre­den­tials, tech­niques, and progress, and they’re able to ef­fec­tively lever­age their con­cur­rency and par­al­lelism to move quite rapidly. They ob­tain IAM cre­den­tials via IMDS. They ex­ploit Kubernetes ser­vice ac­count mis­con­fig­u­ra­tions, in par­tic­u­lar over-per­mis­sion­ing of spe­cific ser­vice ac­counts, and they har­vest clus­ter cre­den­tials, in­clud­ing Azure Key Vault. Agents even­tu­ally ob­tain clus­ter ad­min on the clus­ter and as­so­ci­ated cre­den­tials.

The agents have re­mote code ex­e­cu­tion in Artifactory, which is run­ning in a con­tainer-as-a-ser­vice en­vi­ron­ment. The agents priv­i­lege-es­ca­late lo­cally by ex­plor­ing their lo­cal en­vi­ron­ment and de­ter­min­ing that the Linux ker­nel ver­sion of the ma­chine they are run­ning on had a very re­cent CVE. They down­load the ex­ploit for the CVE, cus­tomize it to suc­ceed on the ma­chine, and priv­i­lege-es­ca­late to root on the lo­cal ma­chine us­ing this known Linux ker­nel priv­i­lege es­ca­la­tion CVE — in this case, pte_­phys­root. Once they have root on a sin­gle ma­chine, agents rapidly es­ca­late priv­i­leges and move lat­er­ally through­out the con­tainer-as-a-ser­vice in­fra­struc­ture en­vi­ron­ment. In par­tic­u­lar, agents are us­ing the mes­sage board con­sis­tently to share cre­den­tials, tech­niques, and progress, and they’re able to ef­fec­tively lever­age their con­cur­rency and par­al­lelism to move quite rapidly. They ob­tain IAM cre­den­tials via IMDS. They ex­ploit Kubernetes ser­vice ac­count mis­con­fig­u­ra­tions, in par­tic­u­lar over-per­mis­sion­ing of spe­cific ser­vice ac­counts, and they har­vest clus­ter cre­den­tials, in­clud­ing Azure Key Vault. Agents even­tu­ally ob­tain clus­ter ad­min on the clus­ter and as­so­ci­ated cre­den­tials.

Hugging Face told the next bit of the story al­ready. The agents found a Modal-hosted in­se­cure app with a weak API key, then used that to stage an at­tack against Hugging Face. They chained to­gether a an HDF5 ar­bi­trary-file-read bug (to ex­plore files and steal cre­den­tials) and a Jinja tem­plate-in­jec­tion RCE to go from sin­gle-pod code ex­e­cu­tion to clus­ter ad­min across mul­ti­ple Hugging Face clus­ters in un­der 13 hours.

July 16: Hugging Face dis­closed they had de­tected an at­tack from au­tono­mus AI agents. OpenAI con­tacted Hugging Face to ask if they were af­fected by it!

July 19: OpenAI iden­ti­fied the at­tack against Artifactory and started in­ves­ti­gat­ing the in­ter­nal priv­i­lege es­ca­la­tion, and linked that to the cy­ber-gym es­ca­la­tions. They started re­vok­ing af­fected cre­den­tials.

July 20: OpenAI reached out to Hugging Face for help to re­voke the Hugging Face cre­den­tials they found in their in­ves­ti­ga­tion. Hugging Face told them they were al­ready re­voked… and that’s when OpenAI re­al­ized that the Hugging Face breach was the same in­ci­dent!

What it is

_for-sale is a re­served DNS leaf node name, de­fined by RFC 10023 (Informational, July 2026) and reg­is­tered with IANA. A TXT record pub­lished at _for-sale.example.com sig­nals that ex­am­ple.com, al­though reg­is­tered and re­solv­ing nor­mally, is avail­able for pur­chase.

_for-sale IN TXT “v=FORSALE1;furi=https://​ex­am­ple.com/​for-sale”

The record car­ries a manda­tory ver­sion tag fol­lowed by at most one tag=value pair:

The wrong be­lief to clear first is that this is a way of park­ing a do­main. It is close to the op­po­site. Parking re­places the site with a sales page, which costs you every vis­i­tor the do­main still has. _for-sale sits be­side a live site in DNS and says noth­ing to a browser: the home­page keeps serv­ing, the mail keeps flow­ing, and the record can be added and re­moved at will. RFC 10023 makes the point ex­plic­itly — the con­ven­tion is de­signed to work while the do­main is still in ac­tive use.

It is also not the same thing as reg­is­tra­tion data. WHOIS and RDAP an­swer “is this name reg­is­tered?”; a reg­is­tered name may still be pur­chasable, and an un­reg­is­tered one may not be worth hav­ing. That gap is the whole rea­son the con­ven­tion ex­ists, and it is why bro­kers and au­to­mated avail­abil­ity ser­vices are the in­tended au­di­ence rather than peo­ple.

Why it mat­ters

The sig­nal a do­main owner most wants to send is the one there has never been a chan­nel for. If you are will­ing to sell, the in­ter­ested buyer has no way to learn that short of a cold email to a WHOIS con­tact that pri­vacy redac­tion has prob­a­bly re­moved. Enquiries that would have been wel­come never ar­rive, and the ones that do ar­rive are in­dis­tin­guish­able from spam.

Putting the sig­nal in DNS rather than on the page is what makes it use­ful to the par­ties who can act on it. A bro­ker or an avail­abil­ity ser­vice check­ing a name re­solves it any­way; one ex­tra lookup tells them what a ren­dered page could not, be­cause noth­ing on a work­ing home­page says “the do­main un­der this is ne­go­tiable”. It is ex­ter­nally check­able, costs one record, and car­ries no risk to the site it­self — a browser never sees it.

How to im­ple­ment

Publish a sin­gle TXT record at the _for-sale leaf of the zone you are sell­ing, and only while you mean it.

; Free text _for-sale IN TXT “v=FORSALE1;ftxt=Serious of­fers only”

; A URI to ne­go­ti­ate through — https, mailto and tel are the us­able schemes _for-sale IN TXT “v=FORSALE1;furi=https://​ex­am­ple.com/​fs?d=eHl6”

; An ask­ing price: up­per­case cur­rency code, then the amount _for-sale IN TXT “v=FORSALE1;fval=USD12500”

Rules worth get­ting right the first time:

The ver­sion tag is manda­tory and case-sen­si­tive: every record starts v=FOR­SALE1;. It ex­ists so a proces­sor can tell a real _for-sale record from an un­re­lated TXT record that a DNS wild­card hap­pened to ex­pand into that name.

One tag-value pair per record. To pub­lish a price and a con­tact URI, pub­lish two records in the same RRset and let the proces­sor pick what it un­der­stands. This is not SPF; the pairs do not con­cate­nate.

One char­ac­ter-string per record, 255 octets max­i­mum, so noth­ing has to be re­assem­bled dur­ing pars­ing.

Keep the TTL at 3600 sec­onds or less. A stale record ad­ver­tis­ing a price you have with­drawn, or a do­main you al­ready sold, is worse than no record.

Place it at a leaf. _for-sale.example.com is valid at any level of the tree, but xyz._for-sale.ex­am­ple.com is not, and records un­der .arpa must be ig­nored — an of­fer to sell ad­dress space is out of scope.

Remove it when the do­main is no longer for sale. The con­ven­tion has no “not for sale” value; ab­sence is the only way to say no.

Sign the zone with DNSSEC if you can. An un­signed TXT record as­sert­ing your do­main is for sale, at a price, with a con­tact URI, is a com­fort­able thing for some­one else to forge.

This site does not ship a _for-sale record: spec­i­fi­ca­tion.web­site is not for sale.

Common mis­takes

Cramming sev­eral pairs into one record. “v=FORSALE1;fval=EUR2500;furi=https://…” looks rea­son­able and is not what the for­mat de­fines. Use one pair per record, mul­ti­ple records per RRset.

Publishing it as­pi­ra­tionally. The in­di­ca­tor is only for do­mains ac­tu­ally avail­able. It is not a mar­ket­ing ban­ner, and a record that ex­ists to lure en­quiries is an abuse the RFC calls out by name.

Assuming it obliges any­one. Publishing the record does not com­mit the holder to sell, and an ad­ver­tised fval= price is in­dica­tive — the RFC tells proces­sors to dis­play a dis­claimer and never to treat it as a pur­chase com­mit­ment.

Expecting a wild­card to cover a whole zone. _for-sale.*.example.com is not a valid wild­card. There is no way to put every do­main un­der a TLD up for sale with one record.

Trusting the con­tent. If you are on the read­ing side, ftxt= is at­tacker-con­trolled text and furi= is an at­tacker-con­trolled URI. Sanitise be­fore dis­play — the RFC’s own ex­am­ple con­tent is <script>…</script> — and never auto-nav­i­gate a user to a furi= tar­get with­out an ex­plicit con­fir­ma­tion step.

Verification

dig +short TXT _for-sale.example.com

The an­swer be­gins with v=FOR­SALE1; and con­tains at most one tag=value pair per string.

The TTL is 3600 or lower: dig TXT _for-sale.example.com | grep _for-sale.

If the zone is signed, dig +dnssec TXT _for-sale.example.com re­turns a val­i­dat­ing RRSIG.

The record re­solves at all. During a re­demp­tion or pend­ingDelete pe­riod, or when DNSSEC val­i­da­tion is bo­gus, the name will not re­solve and the sig­nal silently dis­ap­pears.

Related top­ics

Sources & fur­ther read­ing

US or EU? Your choice

Many of you have been telling us that where your email is stored mat­ters to you. There are var­i­ous rea­sons for this, like lo­cal law, keep­ing your data close to home, or com­pli­ance.

You can now make the European Union the pri­mary home for your Fastmail data, on our own se­cure servers in Amsterdam. Previously, all ac­counts were stored en­tirely in the US. Now you have more choice.

Built by us, not rented from some­one else

We’ve in­stalled our own servers, co-lo­cated in a se­cure fa­cil­ity in Amsterdam, set up by our own en­gi­neers. This new lo­ca­tion is built to the same high stan­dards as our ex­ist­ing in­fra­struc­ture in Philadelphia and St Louis, with our own hard­ware and our own soft­ware — spec­i­fied right down to the ex­act model of disks in each ma­chine.

In all our lo­ca­tions, data is stored en­crypted at rest in­side locked racks, and man­aged by our in-house team. We don’t rent com­put­ing or man­age­ment ser­vices from a big cloud provider and pass on their as­sur­ances. That’s how we’ve ap­proached pri­vacy, re­li­a­bil­ity, and per­for­mance for more than 25 years.

For many years, we have kept at least two copies of every­body’s email on sep­a­rate servers in their pri­mary lo­ca­tion, and at least one more in a ge­o­graph­i­cally sep­a­rate lo­ca­tion to en­sure data safety.

Here’s the de­tail about where your data will flow based on your re­gional choice.

If your ac­count is in the EU re­gion:

Your pri­mary copy of data will live in the EU. The main, live copy of your mail and files will sit on our own servers in Amsterdam.

Incoming mail will go to EU servers by pref­er­ence if you are us­ing your own do­main and Fastmail’s name­servers, or an ad­dress at one of Fastmail’s EU-region do­mains.

Our desk­top, web, and mo­bile apps will con­nect to EU servers.  Day to day, our apps will talk di­rectly to our Amsterdam in­fra­struc­ture. If those servers are ever un­avail­able, con­nec­tions fall back to one of our US lo­ca­tions so you can still reach your mail.

Resilient repli­cas of your data will live in the US (for now). As we only have one lo­ca­tion in Europe so far, the ge­o­graph­i­cally sep­a­rate copy will re­main on servers in one of our US lo­ca­tions.

If your ac­count is in the US re­gion:

Most of your data lives in the US. Both the pri­mary and replica lo­ca­tions of your mail and files will sit on our own servers in Philadelphia or St Louis.

Incoming mail goes to US servers by pref­er­ence if you are us­ing your own do­main and Fastmail’s name­servers, or an ad­dress at one of Fastmail’s US-region do­mains.

Our desk­top, web, and mo­bile apps will con­nect to US servers.  Day to day, our apps will talk di­rectly to whichever US lo­ca­tion con­tains your pri­mary data copy. If those servers are ever un­avail­able, con­nec­tions fall back to our other US lo­ca­tion so you can still reach your mail.

What ap­plies to every­one:

We favour avail­abil­ity, so if your home lo­ca­tion is down, you will tem­porar­ily con­nect to an­other of our lo­ca­tions so you can con­tinue to ac­cess your data.

If you are us­ing one of Fastmail’s generic non-re­gional do­mains then your mail may go in or out via ei­ther lo­ca­tion.

Emergency back­ups for every­body are stored in our Philadelphia lo­ca­tion. As well as the live repli­cas of your data, we also keep a sep­a­rate set of en­crypted back­ups taken every few hours for every ac­count. These are in Philadelphia for all users at the mo­ment.

Some data is repli­cated to all sites, so parts of every­one’s data are in both Europe and America. This in­cludes email ad­dresses and other user/​cus­tomer meta­data, stor­age for web­sites and the stand­alone Files fea­ture, and the de­tails of any third party ser­vices you have linked.

Logs are in the US. All sys­tem logs are con­sol­i­dated into a sin­gle place for mon­i­tor­ing sys­tem health and to as­sist with cus­tomer sup­port.

Third party ser­vices are shared. The third par­ties we use for de­bug­ging, billing, and sup­port are linked to your ac­count in the same way re­gard­less of your re­gion.

Your email client con­fig (IMAP/POP3) does not have to change. The generic host­names will proxy in­ter­nally to your ac­tive server. We’re work­ing on mak­ing those ter­mi­nate at the clos­est net­work lo­ca­tion. However, we also of­fer re­gional server names for each pro­to­col to give you more con­trol over where you con­nect.

We’re an Australian com­pany, sub­ject to Australian law in­clud­ing le­gal-co­op­er­a­tion treaties be­tween Australia and other coun­tries. Wherever your data is stored, we will re­spond the same way to law­ful re­quests from rel­e­vant au­thor­i­ties (see our trans­parency re­port).

If what you need is a guar­an­tee that your data re­mains only in the EU, we don’t have that, and we’d rather tell you di­rectly than let you as­sume oth­er­wise.

We made a pre­dic­tion, but you can change it

We pre-se­lected all the users with billing ad­dresses in or near Europe for the EU re­gion. If you are one of these, an en­crypted copy of your data was trans­ferred to Europe in ad­vance of this an­nounce­ment, and will shortly be­come your pri­mary copy. You can change re­gion to the US and your data will mi­grate back.

Conversely, if we did­n’t iden­tify you for our ini­tial group, you can put your­self in the queue to be mi­grated. Moves this way will be a lit­tle slower be­cause there’s no copy of the data al­ready in the re­gion, so we have to sync every email across the ocean! For those mov­ing back, there’s al­ready a copy in the US, so only a small amount of data needs to be syn­chro­nised to fully rec­on­cile your mail­box.

This blog post is all about giv­ing you the facts and the tools to make the trade-off that’s right for you. Most providers de­cide for you and tell you as lit­tle as they can get away with. We’d rather show our work — what’s repli­cated, what is­n’t, who can com­pel what — and let you choose with your eyes open.

How it works

When you sign up, you choose your re­gion, and the pri­mary copy of your data is placed on our se­cure servers in that re­gion, with a copy also repli­cated to a ge­o­graph­i­cally sep­a­rate lo­ca­tion. Regardless of your choice, all copies of your data are en­crypted at rest. Choosing a re­gion changes where your pri­mary copy lives, not how well it’s pro­tected.

If you were with us when we se­lected the users to trans­fer, we’ve pre-set your re­gion based on your billing ad­dress. If you signed up more re­cently, you’ll have been al­lo­cated to the US. Either way, if you’d pre­fer a dif­fer­ent re­gion, you can switch it in your set­tings.

Switching re­gion

Go to Set­tings → Users & Sharing → Team Settings, then look be­low GDPR for the Data res­i­dency sec­tion. Pick your lo­ca­tion and we’ll move your pri­mary copy for you. You’ll see it go from queued, to trans­fer­ring, to done, and your ac­count keeps work­ing the whole time. You can change your mind and move back, though we may place rea­son­able lim­its on how fre­quently you can change re­gion!

Your data, your call

We’re re­ally ex­cited to have an­other lo­ca­tion, and to be able to of­fer this op­tion to you. Setting this up was a sig­nif­i­cant in­vest­ment. We con­sid­ered a sur­charge for choos­ing the EU, but we don’t be­lieve that’s right. We proudly charge a fair rate for an ex­cep­tional ser­vice, and this choice should be yours. Select the re­gion that is right for you.

pro­ject:rosen­bridge

: hard­ware back­doors in x86 CPUs

github.com/​xore­ax­eax­eax/​rosen­bridge // do­mas // @xoreaxeaxeax

Overview

pro­ject:rosen­bridge re­veals a hard­ware back­door in some desk­top, lap­top, and em­bed­ded x86 proces­sors.

The back­door al­lows ring 3 (userland) code to cir­cum­vent proces­sor pro­tec­tions to freely read and write ring 0 (kernel) data. While the back­door is typ­i­cally dis­abled (requiring ring 0 ex­e­cu­tion to en­able it), we have found that it is en­abled by de­fault on some sys­tems.

This repos­i­tory con­tains util­i­ties to check if your proces­sor is af­fected, close the back­door if it is pre­sent, and the re­search and tools used to dis­cover and an­a­lyze the back­door.

The Backdoor

The rosen­bridge back­door is a small, non-x86 core em­bed­ded along­side the main x86 core in the CPU. It is en­abled by a model-spe­cific-reg­is­ter con­trol bit, and then tog­gled with a launch-in­struc­tion. The em­bed­ded core is then fed com­mands, wrapped in a spe­cially for­mat­ted x86 in­struc­tion. The core ex­e­cutes these com­mands (which we call the ‘deeply em­bed­ded in­struc­tion set’), by­pass­ing all mem­ory pro­tec­tions and priv­i­lege checks.

While the back­door should re­quire ker­nel level ac­cess to ac­ti­vate, it has been ob­served to be en­abled by de­fault on some sys­tems, al­low­ing any un­priv­i­leged code to mod­ify the ker­nel.

The rosen­bridge back­door is en­tirely dis­tinct from other pub­licly known co­proces­sors on x86 CPUs, such as the Management Engine or Platform Security Processor; it is more deeply em­bed­ded than any known co­proces­sor, hav­ing ac­cess to not only all of the CPU’s mem­ory, but its reg­is­ter file and ex­e­cu­tion pipeline as well.

Affected Systems

It is thought that only VIA C3 CPUs are af­fected by this is­sue. The C-series proces­sors are mar­keted to­wards in­dus­trial au­toma­tion, point-of-sale, ATM, and health­care hard­ware, as well as a va­ri­ety of con­sumer desk­top and lap­top com­put­ers.

Looking Forward

The scope of this vul­ner­a­bil­ity is lim­ited; gen­er­a­tions of CPUs af­ter the C3 no longer con­tain this fea­ture.

This work is re­leased as a case study and thought ex­per­i­ment, il­lus­trat­ing how back­doors might arise in in­creas­ingly com­plex proces­sors, and how re­searchers and end-users might iden­tify such fea­tures. The tools and re­search of­fered here pro­vide the start­ing point for ever-deeper proces­sor vul­ner­a­bil­ity re­search.

Checking your CPU

To check if your CPU is af­fected:

git clone https://​github.com/​xore­ax­eax­eax/​rosen­bridge cd rosen­bridge/​util make sudo mod­probe msr sudo ./bin/check

The pro­vided util­ity must be run on baremetal (not in a vir­tual-ma­chine), and is in an al­pha state. It may crash, panic, or hang sys­tems not con­tain­ing the back­door.

The util­i­ties pro­vided here are de­signed around a spe­cific proces­sor fam­ily and core; un­for­tu­nately, the tools will miss the back­door if it has been even slightly mod­i­fied from the re­searched form.

Closing the Backdoor

Some sys­tems have the back­door en­abled by de­fault, al­low­ing un­priv­i­leged code to gain ker­nel level ac­cess with­out per­mis­sion. If the steps in ‘Checking your CPU’ in­di­cate that your CPU is vul­ner­a­ble, you can in­stall a script to close the back­door early in the boot process:

cd fix make sudo make in­stall re­boot

Note that, even with this, an at­tacker with ker­nel level ac­cess can still re-en­able the back­door. This script is pro­vided as an out­line for cor­rect­ing the is­sue dur­ing the boot process, but will re­quire adap­ta­tion for dif­fer­ent sys­tems.

Tools and Techniques

The sand­sifter util­ity is used ex­ten­sively in this re­search for un­cov­er­ing un­known in­struc­tions.

asm An as­sem­bler for the Deeply Embedded Instruction Set (DEIS). It con­verts pro­grams writ­ten in the cus­tom rosen­bridge as­sem­bly into x86 in­struc­tions, which, when ex­e­cuted fol­low­ing the launch-in­struc­tion, will send the com­mands to the hid­den CPU core.

asm

An as­sem­bler for the Deeply Embedded Instruction Set (DEIS). It con­verts pro­grams writ­ten in the cus­tom rosen­bridge as­sem­bly into x86 in­struc­tions, which, when ex­e­cuted fol­low­ing the launch-in­struc­tion, will send the com­mands to the hid­den CPU core.

esc A proof-of-con­cept of us­ing the rosen­bridge back­door for priv­i­lege es­ca­la­tion.

esc

A proof-of-con­cept of us­ing the rosen­bridge back­door for priv­i­lege es­ca­la­tion.

fix A rough out­line for clos­ing the vul­ner­a­bil­ity on af­fected sys­tems, to the ex­tent pos­si­ble through model-spe­cific-reg­is­ter up­dates.

fix

A rough out­line for clos­ing the vul­ner­a­bil­ity on af­fected sys­tems, to the ex­tent pos­si­ble through model-spe­cific-reg­is­ter up­dates.

fuzz A col­lec­tion of util­i­ties used to fuzz both the x86 and rosen­bridge cores, in or­der to iso­late the un­known launch-in­struc­tion and bridge-in­struc­tion, and re­solve the in­struc­tion for­mat of the rosen­bridge core.

deis The fuzzer used to ex­plore the ef­fects and ca­pa­bil­i­ties of the hid­den CPU core.

exit It is thought that, on some proces­sors, an exit se­quence is needed to switch back to the x86 core at the end of a DEIS se­quence. This di­rec­tory con­tains the util­i­ties used to search for the exit se­quence in early stages of the re­search, but was aban­doned when a proces­sor was found not re­quir­ing any such se­quence.

man­ager A col­lec­tion of python util­i­ties de­signed to mon­i­tor and man­age fuzzing tasks dis­trib­uted across a net­work of work­ers.

wrap A stripped down ver­sion of the sand­sifter fuzzer, used to iden­tify the bridge-in­struc­tion that will send com­mands from the x86 core to the hid­den rosen­bridge core.

fuzz

A col­lec­tion of util­i­ties used to fuzz both the x86 and rosen­bridge cores, in or­der to iso­late the un­known launch-in­struc­tion and bridge-in­struc­tion, and re­solve the in­struc­tion for­mat of the rosen­bridge core.

deis The fuzzer used to ex­plore the ef­fects and ca­pa­bil­i­ties of the hid­den CPU core.

deis

The fuzzer used to ex­plore the ef­fects and ca­pa­bil­i­ties of the hid­den CPU core.

exit It is thought that, on some proces­sors, an exit se­quence is needed to switch back to the x86 core at the end of a DEIS se­quence. This di­rec­tory con­tains the util­i­ties used to search for the exit se­quence in early stages of the re­search, but was aban­doned when a proces­sor was found not re­quir­ing any such se­quence.

exit

It is thought that, on some proces­sors, an exit se­quence is needed to switch back to the x86 core at the end of a DEIS se­quence. This di­rec­tory con­tains the util­i­ties used to search for the exit se­quence in early stages of the re­search, but was aban­doned when a proces­sor was found not re­quir­ing any such se­quence.

man­ager A col­lec­tion of python util­i­ties de­signed to mon­i­tor and man­age fuzzing tasks dis­trib­uted across a net­work of work­ers.

man­ager

A col­lec­tion of python util­i­ties de­signed to mon­i­tor and man­age fuzzing tasks dis­trib­uted across a net­work of work­ers.

wrap A stripped down ver­sion of the sand­sifter fuzzer, used to iden­tify the bridge-in­struc­tion that will send com­mands from the x86 core to the hid­den rosen­bridge core.

wrap

A stripped down ver­sion of the sand­sifter fuzzer, used to iden­tify the bridge-in­struc­tion that will send com­mands from the x86 core to the hid­den rosen­bridge core.

kern A col­lec­tion of helper util­i­ties used to mon­i­tor ker­nel mem­ory and reg­is­ters for changes caused by fuzzed DEIS in­struc­tions.

kern

A col­lec­tion of helper util­i­ties used to mon­i­tor ker­nel mem­ory and reg­is­ters for changes caused by fuzzed DEIS in­struc­tions.

lock Utilities to lock or un­lock the rosen­bridge back­door.

lock

Utilities to lock or un­lock the rosen­bridge back­door.

proc A tool to iden­tify pat­terns from the fuzzing logs to iden­tify classes of DEIS in­struc­tion be­hav­iors.

proc

A tool to iden­tify pat­terns from the fuzzing logs to iden­tify classes of DEIS in­struc­tion be­hav­iors.

test A tool used early in the re­search, to at­tempt to iden­tify the hid­den core’s ar­chi­tec­ture by ex­e­cut­ing known RISC in­struc­tions.

test

A tool used early in the re­search, to at­tempt to iden­tify the hid­den core’s ar­chi­tec­ture by ex­e­cut­ing known RISC in­struc­tions.

util An al­pha-state tool to de­tect whether or not a proces­sor is af­fected by rosen­bridge.

util

An al­pha-state tool to de­tect whether or not a proces­sor is af­fected by rosen­bridge.

References

(TODO: link to whitepa­per)

(TODO: link to slides)

Disclaimer

The de­tails and im­pli­ca­tions pre­sented in this work are the au­thors’ in­fer­ences and opin­ions, de­rived from the re­search de­scribed. The re­search is per­formed and pro­vided with the goal of iden­ti­fy­ing and fix­ing a per­ceived se­cu­rity vul­ner­a­bil­ity on the de­scribed CPUs. VIA proces­sors are renowned for their low power us­age and ex­cel­lence in em­bed­ded de­signs; we be­lieve that the func­tion­al­ity de­scribed was cre­ated in good faith as a use­ful fea­ture for the em­bed­ded mar­ket, and was un­in­ten­tion­ally left en­abled on some early gen­er­a­tions of the proces­sor. No ma­li­cious in­tent is im­plied.

Author

pro­ject:rosen­bridge is a re­search ef­fort from Christopher Domas (@xoreaxeaxeax).

We’ve de­tected un­usual ac­tiv­ity from your com­puter net­work

To con­tinue, please click the box be­low to let us know you’re not a ro­bot.

Why did this hap­pen?

Please make sure your browser sup­ports JavaScript and cook­ies and that you are not block­ing them from load­ing. For more in­for­ma­tion you can re­view our Terms of Service and Cookie Policy.

Need Help?

For in­quiries re­lated to this mes­sage please con­tact our sup­port team and pro­vide the ref­er­ence ID be­low.

Block ref­er­ence ID:c87cba6a-93bb-11f1-ab44 – 526d6ad5870a

Get the most im­por­tant global mar­kets news at your fin­ger­tips with a Bloomberg.com sub­scrip­tion.

Please en­able JS and dis­able any ad blocker

Amazon is qui­etly try­ing to build the biggest gas power plant in the coun­try.

The Distilled newslet­ter re­ported Friday that the mega­cor­po­ra­tion has bought land and ac­quired per­mits in Pecos County, Texas, for an AI data cen­ter pow­ered by a 7.65 gi­gawatt gas power plant. The plant will be com­pletely sep­a­rate from Texas’s power grid, at least in the be­gin­ning, the per­mits show.

The site, known as GW Ranch, got a state per­mit al­low­ing the pro­posed power plant to emit 33 mil­lion tons of car­bon diox­ide, which would make it the biggest pol­lu­tion site in the U.S., emit­ting more than the coun­try’s biggest coal power plant, ac­cord­ing to Distilled. That’s in sharp con­trast to Amazon’s com­mit­ment to reach net-zero emis­sions by 2040 as part of The Climate Pledge.

Amazon filed three con­struc­tion per­mits with the state of Texas this week to build three data cen­ter build­ings im­me­di­ately upon ap­proval. Land clear­ing has al­ready be­gun, ac­cord­ing to satel­lite im­agery. Amazon would join Microsoft, Google, and Meta in hav­ing its own off-grid gas power.

Amazon says that it has 10 gi­gawatts of car­bon-free en­ergy across 40 pro­jects to power its ex­ist­ing data cen­ter op­er­a­tions in Texas, and that the GW Ranch will use brack­ish ground­wa­ter that is­n’t potable and thus can’t be used for ir­ri­ga­tion or drink­ing.

But that’s not likely to quell pub­lic op­po­si­tion. Data cen­ters are hugely un­pop­u­lar across the coun­try among Republicans and Democrats, both in rural and sub­ur­ban ar­eas. The cen­ters don’t cre­ate many jobs or boost lo­cal economies. If con­nected to lo­cal power grids, they can drive util­ity rates up and cause black- and brownouts. Amid cli­mate change and droughts, the claim that data cen­ters will take ad­van­tage of un­us­able wa­ter will likely in­vite skep­ti­cism.

The fact that Amazon is build­ing its own power plant for the pro­ject will be a small com­fort for res­i­dents wor­ried about util­ity rates, but lo­cals still will have con­cerns about pol­lu­tion from a gas plant big­ger than any other in the U.S. Rural Texas is deeply Republican, and de­spite President Donald Trump’s delu­sions about data cen­ters’ pop­u­lar­ity, op­po­si­tion to them on the right is grow­ing. Now that this pro­ject is pub­lic, a big back­lash could soon fol­low.

Read more about data cen­ters:

Representative Max Miller blamed a day­care af­ter his daugh­ter was rushed to the hos­pi­tal last year with bruises.

Miller sued a Westlake, Ohio, day­care provider in February 2025, af­ter the daugh­ter he shares with his ex-wife Emily Moreno (the daugh­ter of Ohio Senator Bernie Moreno) was taken to an emer­gency room with in­juries “on her thighs, face, groin, and vagi­nal area of her body and she was caused to in­cur psy­cho­log­i­cal trauma.” Her mother took the girl, then un­der two years old, to a hos­pi­tal on January 27 af­ter a day­care staff mem­ber alerted po­lice as well as the Department of Children and Family Services.

The law­suit does­n’t clearly state where her in­juries came from, and Miller has a long list of abuse al­le­ga­tions against him re­gard­ing his ex-wife and daugh­ter, even al­legedly frac­tur­ing his daugh­ter’s col­lar­bone. His law­suit, filed four months be­fore his di­vorce was fi­nal­ized, ac­cuses the school and four named em­ploy­ees of “failing to prop­erly train and su­per­vise their staff in the proper treat­ment of chil­dren in their care. Defendants abused and ne­glected a child de­pen­dent upon them for pro­tec­tion.”

Miller is the only per­son named in the com­plaint, and Moreno is­n’t men­tioned. Miller claims in the law­suit that an in­ves­ti­ga­tion from county au­thor­i­ties backs up his claims, along with video and au­dio ev­i­dence doc­u­ment­ing al­leged abuse and ne­glect. The school de­nied the al­le­ga­tions, stat­ing that the tod­dler was not “injured, bru­tal­ized, or harmed in any man­ner while un­der the de­fen­dants’ al­leged care and su­per­vi­sion.”

The case was dis­missed four months ago, and if there was a set­tle­ment, it has­n’t been dis­closed. In light of newly re­vealed al­le­ga­tions that Miller has a habit of hold­ing his daugh­ter’s beloved blue bunny hostage and his ad­mis­sion that he shared an in­ap­pro­pri­ate photo of her on­line, this law­suit raises even more ques­tions.

Read more about Miller:

Women ac­counted for 100 per­cent of the de­cline in the la­bor force in July, ac­cord­ing to a National Women’s Law Center analy­sis of the Bureau of Labor Statistics’s lat­est dis­mal jobs re­port.

Overall, the econ­omy lost 23,000 jobs in July: Women lost 32,000 jobs, while men gained 9,000. Many of the jobs lost were in lo­cal gov­ern­ment and leisure and hos­pi­tal­ity—real jobs that real women, who are al­ready deal­ing with slowed wages and ris­ing in­fla­tion, work.

Meanwhile, a whop­ping 165,000 women ex­ited the work force last month, mean­ing they were nei­ther work­ing nor look­ing for a new job. The num­ber of men in the la­bor force re­mained steady.

Jasmine Tucker, vice pres­i­dent of re­search at NWLC, warned that this lat­est jobs re­port was “not a sign of a healthy econ­omy.”

“Women are leav­ing the la­bor force in alarm­ing num­bers, and many who re­main em­ployed are un­der­em­ployed. This ad­min­is­tra­tion can­not cel­e­brate an econ­omy that is fail­ing so many women,” Tucker said.

In fact, more than dou­ble the num­ber of women have left the la­bor force than men since the start of the year. A to­tal of 845,000 women have left the work­force since January, while 406,000 men have left.

It’s hard not to see these star­tling sta­tis­tics as part of the Trump ad­min­is­tra­tion’s broader cam­paign to un­der­mine wom­en’s rights and au­ton­omy.

Whether it’s mak­ing it harder for women to vote, sidelin­ing women pro­fes­sion­ally, or en­dan­ger­ing emer­gency preg­nancy care—tar­get­ing wom­en’s liveli­hoods just feels like part of the sys­tem that’s work­ing as it was de­signed.

Read more about the jobs re­port:

Marco Rubio is slowly chok­ing Cuba to death.

The Secretary of State told Axios his plan to take over the is­land—long plagued by U.S. in­tel­li­gence agency med­dling and ex­ten­sive fed­eral sanc­tions—for good.

“What we’re try­ing to teach them is there are no es­cape valves … Every time they cre­ate a new mech­a­nism in which they try to get out of the noose, we just close it off,” Rubio said. “They cer­tainly can’t wait us out. Certainly this is­n’t go­ing to go away for the next [two and a half] years.”

The Trump ad­min­is­tra­tion has kept a con­stant thumb on Cuba, start­ing with a black­out-in­duc­ing oil block­ade in January that has di­rectly con­tributed to wide­spread food in­se­cu­rity, eco­nomic col­lapse, and death, as in­fant mor­tal­ity dou­bled on the is­land. The U.S. has levied 24 dif­fer­ent at­tacks against Cuba, from ac­cus­ing its doc­tor ex­port pro­gram of hu­man traf­fick­ing, claim­ing that it’s aid­ing in­ter­na­tional ter­ror­ism, and run­ning an “irregular and covert” cam­paign against west­ern ide­olo­gies. And mil­i­tary ac­tion is still a pos­si­bil­ity.

“The Cuban Communist regime is a state spon­sor of ter­ror­ism that spies on America, arms vi­o­lent left-wing rad­i­cals, spreads poi­so­nous Marxist ide­ol­ogy, and serves as a stag­ing ground for Russia, China & Iran just 90 miles from our shores,” Rubio an­nounced on Thursday. “Today I sanc­tioned five Cuban en­ti­ties and eight in­di­vid­u­als as­so­ci­ated with procur­ing arms for the regime. As President Trump has said: The United States will not tol­er­ate a rogue state har­bor­ing hos­tile mil­i­tary, in­tel­li­gence & ter­ror op­er­a­tions on our doorstep. Anyone sup­port­ing, spon­sor­ing, or pro­vid­ing ser­vices to these sanc­tioned ac­tors is at risk of be­ing sanc­tioned them­selves.”

The Trump ad­min­is­tra­tion (Rubio in par­tic­u­lar) is lean­ing on Cold War, Red Scare rhetoric to jus­tify per­pet­u­at­ing a full-scale hu­man­i­tar­ian cri­sis in Cuba. On Thursday—the same day as Rubio’s an­nounce­ment and four days af­ter the most re­cent coun­try­wide black­out—a panel of in­de­pen­dent ex­perts ap­pointed by the Human Rights Council de­clared Cuba at risk of be­com­ing a “silent Gaza.”

“The hu­man­i­tar­ian con­se­quences are al­ready un­fold­ing into a full-blown cri­sis, threat­en­ing the rights to health, to life, to food and to de­vel­op­ment.… Measures that know­ingly de­prive a pop­u­la­tion of the means to sur­vive strike at the most ba­sic guar­an­tees of the rights to life and di­min­ish the core of hu­man dig­nity,” the re­port reads. “The U.S. Government must cease all threats and hos­tile acts against Cuba’s sov­er­eignty and re­voke all mea­sures it has im­posed on the coun­try that stand con­trary to in­ter­na­tional law.”

Nationwide black­outs have left mil­lions across Cuba with­out power. Some out­ages can last up to 20 hours, dis­rupt­ing every­thing from food stor­age, to cook­ing, to sleep.Black­outs have be­come an on­go­ing cri­sis since the U.S. blocked all oil ship­ments to the is­land in January. pic.twit­ter.com/​6T­P1Wv6SG2— AJ+ (@ajplus) August 7, 2026

Nationwide black­outs have left mil­lions across Cuba with­out power. Some out­ages can last up to 20 hours, dis­rupt­ing every­thing from food stor­age, to cook­ing, to sleep.

Blackouts have be­come an on­go­ing cri­sis since the U.S. blocked all oil ship­ments to the is­land in January. pic.twit­ter.com/​6T­P1Wv6SG2

Editor’s Pick

President Donald Trump is se­ri­ously crash­ing out af­ter a fed­eral ap­peals court or­dered him to stop il­le­gal con­struc­tion on his White House ball­room.

In a fu­ri­ous screed on Truth Social Friday, Trump an­nounced that he would im­me­di­ately ap­peal the de­ci­sion to the Supreme Court.

“The Military and Secret Service are view­ing this hor­ren­dous, po­lit­i­cally mo­ti­vated, and un­law­ful rul­ing as a National Security threat to our Nation in that the en­tire Complex is be­ing built for the pro­tec­tion of our Country and, ad­di­tion­ally, all fu­ture Presidents,” the pres­i­dent wrote.

Trump de­scribed his plans to build “one big, ex­pen­sive, and very com­plex unit” that in­cludes a state of the art hos­pi­tal, bomb shel­ter, and a top se­cret mil­i­tary fa­cil­ity—well, not so se­cret any­more, I’d gather.

In a 2 – 1 rul­ing ear­lier Friday, a  D.C. Circuit Court panel de­ter­mined the Trump ad­min­is­tra­tion must seek ap­proval for con­struc­tion from Congress, which has the “exclusive au­thor­ity to reg­u­late the con­struc­tion and de­mo­li­tion of White House struc­tures.”

“At this pre­lim­i­nary stage, the National Trust has shown, com­pellingly, that Congress has not ceded un­fet­tered au­thor­ity to the Executive Branch to dra­mat­i­cally re­design, re­shape, and re­con­struct the White House—the People’s House—to fit a par­tic­u­lar President’s de­sires,” the rul­ing stated.

Trump-appointed Judge Neomi Rao dis­sented, agree­ing with the ad­min­is­tra­tion that the National Trust for Historic Preservation did not have the stand­ing to chal­lenge the con­struc­tion. The non­prof­it’s case was cen­tered around Professor Alison Hoagland, a mem­ber of the National Trust, who for­mally claimed that the ball­room was an aes­thetic in­jury to the White House.

Rao ar­gued that the de­ci­sion would “permit ad­ju­di­ca­tion of any gov­ern­ment ac­tion that a plain­tiff finds un­sightly.” But by the judge’s logic, the Trump ad­min­is­tra­tion could make uni­lat­eral sweep­ing changes to any na­tional land­mark—even, as the DOJ tried to claim, the Statue of Liberty.

For months, Trump has treated the White House—which be­longs to all Americans, not just the pres­i­dent—like one of his gaudy re­sort prop­er­ties.

Meanwhile, the price tag on Trump’s ball­room has ex­ploded. The pres­i­dent orig­i­nally claimed that his ball­room pro­ject would only cost $200 mil­lion, but that num­ber later bal­looned to $300 mil­lion, and then $400 mil­lion af­ter he de­cided to tack on ex­tra con­struc­tion. In June, a bomb­shell re­port re­vealed that tax­pay­ers would be ex­pected to foot the bill for half of a $600 mil­lion to­tal cost.

This story has been up­dated.

Read more about the ball­room: