Artemis II is NASA’s first crewed mis­sion un­der the Artemis pro­gram and will launch from the agen­cy’s Kennedy Space Center in Florida. It will send NASA as­tro­nauts Reid Wiseman, Victor Glover, Christina Koch, and CSA (Canadian Space Agency) as­tro­naut Jeremy Hansen on an ap­prox­i­mately 10-day jour­ney around the Moon. Among ob­jec­tives, the agency will test the Orion space­craft’s life sup­port sys­tems for the first time with peo­ple and lay the ground­work for fu­ture crewed Artemis mis­sions.

Live up­dates for launch of NASA’s Artemis II test flight will be pub­lished on this page. NASA’s launch broad­cast cov­er­age is air­ing on NASA+, Ama­zon Prime, and YouTube. All times are Eastern.

The Orion space­craft’s SAWs (solar ar­rays wings) have fully de­ployed, com­plet­ing a key con­fig­u­ra­tion step for the Artemis II mis­sion. Flight con­trollers in Houston con­firmed that all four wings un­folded as planned, lock­ing into place and be­gin­ning to draw power.

Each so­lar ar­ray wing ex­tends out­ward from the European Service Module, giv­ing Orion, named Integrity, a wingspan of roughly 63 feet when fully de­ployed. Each wing has 15,000 so­lar cells to con­vert sun­light to elec­tric­ity. The ar­rays can turn on two axes that al­low them to ro­tate and track the Sun, max­i­miz­ing power gen­er­a­tion as the space­craft changes at­ti­tude dur­ing its time in Earth or­bit and on its out­bound jour­ney to the Moon.

The next ma­jor mile­stones are the PRM (perigee raise ma­neu­ver) and ARB (apogee raise burn) that will in­crease the low­est and high­est points of the Orion space­craft’s or­bit and pre­pare the space­craft for deep‑space op­er­a­tions.

Following the burns, NASA will hold a post­launch news con­fer­ence at 9 p.m. from Kennedy Space Center in Florida. Following the news con­fer­ence, the Artemis II crew will be­gin prepa­ra­tions for Orion’s prox­im­ity op­er­a­tions demon­stra­tion. This demon­stra­tion will test the abil­ity to man­u­ally ma­neu­ver Orion rel­a­tive to an­other space­craft, in this case, the in­terim cryo­genic propul­sion stage af­ter sep­a­ra­tion.

Coverage on NASA+ will soon con­clude, how­ever 24/7 cov­er­age will con­tinue on NASA’s YouTube chan­nel, and keep fol­low­ing the Artemis blog for live up­dates of key mile­stones through­out the mis­sion.

Main en­gine cut­off of the SLS (Space Launch System) core stage is com­plete, and the core stage has suc­cess­fully sep­a­rated from the in­terim cryo­genic propul­sion stage and the Orion space­craft. This marks the end of the first ma­jor propul­sion phase of the Artemis II mis­sion and the tran­si­tion to up­per‑stage op­er­a­tions.

The next ma­jor mile­stone is the de­ploy­ment of the space­craft’s SAWs (solar ar­ray wings) sched­uled to be­gin ap­prox­i­mately 18 min­utes af­ter launch. Once ex­tended, the four SAWs will pro­vide con­tin­u­ous elec­tri­cal power to the space­craft through­out its jour­ney, sup­port­ing life‑sup­port sys­tems, avion­ics, com­mu­ni­ca­tions, and on­board op­er­a­tions. Deployment is a crit­i­cal step in con­fig­ur­ing Orion for the re­main­der of its time in Earth or­bit and for the out­bound trip to the Moon.

The space­craft adapter jet­ti­son fair­ings that en­close the ser­vice mod­ule and the launch abort sys­tem have sep­a­rated from the Orion space­craft. With the rocket and space­craft now fly­ing above the dens­est lay­ers of Earth’s at­mos­phere, Orion no longer re­quires the pro­tec­tive struc­tures that shielded it dur­ing the early, high‑dy­namic‑pres­sure por­tion of launch.

The next ma­jor mile­stone is core stage sep­a­ra­tion and Interim Cryogenic Propulsion Stage ig­ni­tion.

The SLS (Space Launch System) twin solid rocket boost­ers have sep­a­rated. The boost­ers, each stand­ing 177 feet tall and gen­er­at­ing more than 3.6 mil­lion pounds of thrust at liftoff, pro­vide most of the rock­et’s power dur­ing the first two min­utes of flight and sep­a­ra­tion re­duces mass and al­lows the core stage to con­tinue pro­pelling the Orion space­craft, named Integrity, to­ward or­bit.

With the boost­ers now clear, the SLS core stage re­mains the pri­mary source of thrust.

In about one minute, the space­craft adapter jet­ti­son fair­ings that en­close Orion’s ser­vice mod­ule and the launch abort sys­tem will sep­a­rate from the space­craft.

6:35 p.m.

NASA’s Artemis II SLS (Space Launch System) rocket, with the Orion spacecraft atop car­ry­ing NASA as­tro­nauts Reid Wiseman, Victor Glover, and Christina Koch, along with CSA (Canadian Space Agency) as­tro­naut Jeremy Hansen, lifted off from Kennedy Space Center’s Launch Complex 39B in Florida at 6:35 p.m. EDT to be­gin its jour­ney to deep space.

The twin solid rocket boost­ers ig­nited first, de­liv­er­ing more than 75% of the thrust needed to lift the 5.75-million-pound rocket off the pad. Their com­bined power, along with the four RS-25 en­gines al­ready at full thrust, gen­er­ated an in­cred­i­ble 8.8 mil­lion pounds of force at liftoff. As the rocket rose, the um­bil­i­cals — which pro­vided power, fuel, and data con­nec­tions dur­ing prelaunch — dis­con­nected and re­tracted into pro­tec­tive hous­ings. This en­sured the ve­hi­cle is free from ground sys­tems and fully au­tonomous for flight.

The ap­prox­i­mately 10-day Artemis II mis­sion around the Moon is the first crewed flight un­der NASA’s Artemis cam­paign. It will help test the sys­tems and hard­ware needed to con­tinue send­ing as­tro­nauts on in­creas­ingly dif­fi­cult mis­sions to ex­plore more of the Moon for sci­en­tific dis­cov­ery, eco­nomic ben­e­fits, and to con­tinue build­ing to­ward the first crewed mis­sions to Mars.

Below are the as­cent mile­stones that will oc­cur lead­ing up to core stage sep­a­ra­tion. Times may vary by sev­eral sec­onds.

The Artemis II count­down has en­tered ter­mi­nal count, and the ground launch se­quencer has taken con­trol, or­ches­trat­ing a pre­cise se­ries of au­to­mated com­mands to pre­pare the SLS (Space Launch System) rocket and Orion space­craft for liftoff at a T-0 time of 6:35 p.m. EDT.

The ground launch se­quencer en­sures that all sys­tems – from propul­sion to avion­ics – tran­si­tion into flight mode. Key ac­tions per­formed in­clude pres­sur­iz­ing pro­pel­lant tanks for op­ti­mal en­gine per­for­mance, ac­ti­vat­ing flight soft­ware and switch­ing con­trol from ground to on­board sys­tems, and per­form­ing fi­nal health checks across thou­sands of sen­sors to con­firm readi­ness.

This au­to­mated se­quence min­i­mizes hu­man in­ter­ven­tion, re­duc­ing risk and en­sur­ing syn­chro­niza­tion across com­plex sub­sys­tems. For Artemis II, this mo­ment marks the cul­mi­na­tion of years of plan­ning and test­ing, as the mis­sion moves from ground op­er­a­tions to the thresh­old of launch.

See the list be­low of the ter­mi­nal count mile­stones:

* T-4M — GLS is go for core stage aux­il­iary power unit (APU) start

Inside the ter­mi­nal count­down, teams have a few op­tions to hold the count if needed.

The launch team can hold at 6 min­utes for the du­ra­tion of the launch win­dow, less the 6 min­utes needed to launch, with­out hav­ing to re­cy­cle back to 10 min­utes.

If teams need to stop the clock be­tween T-6 min­utes and T-1 minute, 30 sec­onds, they can hold for up to 3 min­utes and re­sume the clock to launch. If they re­quire more than 3 min­utes of hold time, the count­down would re­cy­cle back to T-10.

If the clock stops af­ter T-1 minute and 30 sec­onds, but be­fore the au­to­mated launch se­quencer takes over, then teams can re­cy­cle back to T-10 to try again, pro­vided there is ad­e­quate launch win­dow re­main­ing.

After han­dover to the au­to­mated launch se­quencer, any is­sue that would stop the count­down would lead to con­clud­ing the launch at­tempt for that day.

Artemis II Launch Director Charlie Blackwell-Thompson conducted one of the most im­por­tant steps be­fore liftoff: the “go/no-go” poll for the team to pro­ceed with the fi­nal 10 min­utes of the count­down known as ter­mi­nal count.

A unan­i­mous “go” across the board sig­nals that Artemis II is fully pre­pared to pro­ceed to­ward launch. This mo­ment rep­re­sents the cul­mi­na­tion of years of plan­ning and hours of metic­u­lous pre-launch work, bring­ing the mis­sion to the thresh­old of his­tory.

The launch team has made the de­ci­sion to ex­tend the T-10 minute hold ahead of to­day’s launch to give en­gi­neers time to work through fi­nal prepa­ra­tions for liftoff. There is a two-hour win­dow in which Artemis II could launch, and a new liftoff time will be set shortly

NASA’s Artemis II closeout crew com­pleted its fi­nal tasks and de­parted Launch Complex 39B at NASA’s Kennedy Space Center in Florida. After hours of metic­u­lous work as­sist­ing the as­tro­nauts with suit-up, hatch clo­sure, and crit­i­cal space­craft checks, the team ex­ited the White Room and left the Orion space­craft sealed and ready for flight.

This de­par­ture marks a ma­jor tran­si­tion in launch op­er­a­tions: the space­craft is now fully con­fig­ured, and re­spon­si­bil­ity shifts to the launch con­trol team for the fi­nal count­down. The close­out crew’s pre­ci­sion and ex­per­tise en­sure that every con­nec­tion, seal, and sys­tem is ver­i­fied be­fore they step away – mak­ing this mo­ment a key mile­stone on the path to liftoff.

Engineers in­ves­ti­gated a sen­sor on the launch abort sys­tem’s at­ti­tude con­trol mo­tor con­troller bat­tery that showed a higher tem­per­a­ture than would be ex­pected. It is be­lieved to be an in­stru­men­ta­tion is­sue and will not af­fect to­day’s launch.

The weather con­tin­ues to co­op­er­ate and has now been up­graded to 90% go for launch.

Engineers have now re­solved an is­sue with the hard­ware that com­mu­ni­cates with the flight ter­mi­na­tion sys­tem that would have pre­vented the ground from send­ing a sig­nal to de­struct the rocket if it were to veer off course dur­ing as­cent, to pro­tect pub­lic safety. A con­fi­dence test was per­formed to en­sure that the hard­ware is ready to sup­port to­day’s launch.

Meanwhile, tech­ni­cians have com­pleted the launch abort sys­tem hatch clo­sure – an es­sen­tial step that en­sures the Orion space­craft is fully sealed and ready for flight. The hatch pro­vides an ad­di­tional pro­tec­tive bar­rier for the crew mod­ule, de­signed to safe­guard as­tro­nauts dur­ing the Artemis II flight path and, if nec­es­sary, en­able a rapid es­cape in the event of an emer­gency.

During this phase, the close­out team ver­i­fies hatch align­ment, en­gages lock­ing mech­a­nisms, and con­firms pres­sure in­tegrity. These checks guar­an­tee that the launch abort sys­tem hatch can per­form its func­tion flaw­lessly, main­tain­ing struc­tural in­tegrity un­der ex­treme launch con­di­tions. With the hatch se­cured, Orion en­ters its fi­nal con­fig­u­ra­tion for liftoff, mark­ing one of the last ma­jor mile­stones be­fore fu­el­ing and launch.

Although the count­down to to­day’s Artemis II launch is con­tin­u­ing to progress, the Eastern Range has iden­ti­fied an is­sue that they are cur­rently work­ing to re­solve re­lated to their com­mu­ni­ca­tion with the flight ter­mi­na­tion sys­tem. The flight ter­mi­na­tion sys­tem is a safety sys­tem that al­lows en­gi­neers on the ground to send a sig­nal to de­struct the rocket if it were to veer off course dur­ing as­cent, to pro­tect pub­lic safety. Without as­sur­ance that this sys­tem would work if needed, to­day’s launch would be no-go. However, en­gi­neers have de­vised a way to ver­ify the sys­tem and are cur­rently prepar­ing to test this so­lu­tion.

Technicians be­gan in­stalling the crew mod­ule hatch ser­vice panel on the Orion space­craft, an im­por­tant step in fi­nal launch prepa­ra­tions. This panel pro­tects key con­nec­tions and en­sures the hatch area is se­cure for flight.

As part of cur­rent close­out ac­tiv­i­ties, teams are con­firm­ing all sys­tems around the hatch are prop­erly sealed and ready for the mis­sion.

With the hatch area se­cured, teams will con­tinue fi­nal checks and count­down op­er­a­tions at Launch Pad 39B at NASA’s Kennedy Space Center in Florida, bring­ing us closer to send­ing as­tro­nauts on a his­toric jour­ney around the Moon.

NASA en­gi­neers have con­ducted coun­ter­bal­ance mech­a­nism op­er­a­tions and are now per­form­ing hatch seal pres­sure de­cay checks in­side the White Room at Launch Complex 39B. These steps en­sure Orion’s hatch main­tains proper pres­sure in­tegrity and that the coun­ter­bal­ance sys­tem func­tions as de­signed for launch con­di­tions.

The coun­ter­bal­ance mech­a­nism is a pre­ci­sion-en­gi­neered as­sem­bly that off­sets the weight of the crew mod­ule hatch, al­low­ing tech­ni­cians to open and close it smoothly with­out in­tro­duc­ing stress on the hinge or seal. This sys­tem uses cal­i­brated springs and dampers to main­tain align­ment and pre­vent sud­den move­ments, which is es­sen­tial for pre­serv­ing the hatch’s air­tight seal. During this phase, tech­ni­cians ver­ify the mech­a­nis­m’s load dis­tri­b­u­tion and con­firm that its lock­ing fea­tures en­gage cor­rectly un­der sim­u­lated launch loads.

Following these ad­just­ments, the team per­forms seal pres­sur­iza­tion de­cay checks – mon­i­tor­ing pres­sure loss over time to con­firm the hatch’s in­tegrity. These checks are vi­tal for as­tro­naut safety, en­sur­ing the cabin re­mains se­cure in all mis­sion phases.

NASA’s Artemis II close­out crew is now com­plet­ing one of the most crit­i­cal steps be­fore launch: prepar­ing and clos­ing the crew mod­ule hatch to the Orion space­craft. Inside the White Room at Launch Complex 39B, the close­out crew is work­ing metic­u­lously to in­spect seals, se­cure fas­ten­ers, and ver­ify that the hatch is air­tight.

This process en­sures Orion is fully pres­sur­ized and ready for flight. Once the hatch is closed and locked, the as­tro­nauts are of­fi­cially sealed in­side their space­craft, mark­ing a ma­jor mile­stone on the path to liftoff.

NASA’s Artemis II crew mem­bers are board­ing the agen­cy’s Orion space­craft to be­gin com­mu­ni­ca­tion checks to con­firm voice links with mis­sion con­trol and on­board sys­tems.

Before en­ter­ing the space­craft that will be their home on the ap­prox­i­mately 10-day jour­ney around the Moon and back, all four crew­mates signed the in­side of the White Room, an area at the end of the crew ac­cess arm that pro­vides ac­cess to the space­craft. The term “White Room” dates to NASA’s Gemini pro­gram, and to honor this hu­man space­flight tra­di­tion, the room re­mains white to­day.

The Artemis II closeout crew is now work­ing to help the as­tro­nauts en­ter the Orion space­craft and make fi­nal prepa­ra­tions for their nearly 700,000-mile trip to the Moon and back. As part of the process, the close­out crew is help­ing the as­tro­nauts don their Orion Crew Survival System helmets and gloves, as well as board Orion and get buck­led in.

A short time from now, the close­out crew will close the crew mod­ule and ex­te­rior launch abort sys­tem hatches. Even a sin­gle strand of hair in­side the hatch doors could po­ten­tially pose is­sues with clos­ing ei­ther hatch, so the process is care­fully done and takes up to four hours. Each step in the close­out process en­sures air­tight seals and com­mu­ni­ca­tion readi­ness for the mis­sion ahead.

Following com­mu­ni­ca­tion checks, the team per­formed suit leak checks – a vi­tal safety pro­ce­dure en­sur­ing each pres­sure suit main­tains in­tegrity in case of cabin de­pres­sur­iza­tion. These op­er­a­tions are es­sen­tial for crew readi­ness and mis­sion as­sur­ance, mark­ing one of the fi­nal phases be­fore hatch clo­sure and launch prepa­ra­tions.

With assistance from the close­out crew, the Artemis II crew are care­fully don­ning their hel­mets and gloves – fi­nal­iz­ing suit in­tegrity checks be­fore board­ing the Orion space­craft.

This step is more than cer­e­mo­nial; it en­sures air­tight seals and com­mu­ni­ca­tion readi­ness for the mis­sion ahead. The close­out crew plays a vi­tal role, guid­ing the as­tro­nauts through these pro­ce­dures and con­firm­ing every con­nec­tion is se­cure be­fore hatch clo­sure.

Stay tuned as we con­tinue to fol­low the Artemis II team through each count­down mile­stone on their path to liftoff.

NASA’s Artemis II crew NASA as­tro­nauts Reid Wiseman, Victor Glover, and Christina Koch, along with CSA (Canadian Space Agency) as­tro­naut Jeremy Hansen, arrived at Launch Complex 39B at the agen­cy’s Kennedy Space Center in Florida, where the agen­cy’s SLS (Space Launch System) rocket with Orion space­craft atop stands ready for launch. The open­ing of to­day’s launch win­dow is slated for just over 4 hours from now, at 6:24 p.m. EDT.

In the next few min­utes, the crew will take the el­e­va­tor up the pad’s fixed ser­vice struc­ture and walk down the cli­mate-con­trolled crew ac­cess arm to the White Room, their fi­nal stop be­fore climb­ing aboard their Orion space­craft. In this clean, con­trolled en­vi­ron­ment at the end of the crew ac­cess arm, the close­out crew will as­sist the as­tro­nauts with hatch op­er­a­tions and ver­ify that all safety sys­tems are ready for launch.

Since the late 1960s, pads A and B at Kennedy’s Launch Complex 39 have sup­ported America’s ma­jor space pro­grams, with Pad A used most fre­quently for launches un­der the Space Shuttle Program. After the re­tire­ment of the shut­tle in 2011, Pad A helped usher in a new era of hu­man space­flight as launch pad for the agen­cy’s Commercial Crew Program, which re­turned hu­man space­flight ca­pa­bil­ity to the United States. Pad B saw the launch of NASA’s Artemis I mis­sion in November 2022 and will con­tinue to be the pri­mary launch pad for America’s ef­forts to re­turn to hu­mans the Moon.

Just mo­ments ago, NASA’s Artemis II flight crew be­gan the walk that every NASA as­tro­naut has made since Apollo 7 in 1968, head­ing to the el­e­va­tor and down through the dou­ble doors be­low the Neil A. Armstrong Building’s Astronaut Crew Quarters at NASA’s Kennedy Space Center in Florida.

Before they left the suit-up room, the crew com­pleted one last piece of un­fin­ished busi­ness — a card game. A long-held space­flight tra­di­tion, NASA crews play cards be­fore leav­ing the crew quar­ters ahead of launch un­til the com­man­der, in this in­stance NASA as­tro­naut Reid Wiseman, loses. It is hoped that by los­ing, the com­man­der burns off all his or her bad luck, thereby clear­ing the mis­sion for only good luck.

NASA’s Artemis II is the first crewed mis­sion of the Artemis pro­gram and will carry Wiseman and fel­low NASA as­tro­nauts Vic­tor Glover and Christina Koch, as well as CSA (Canadian Space Agency) as­tro­naut Jeremy Hansen on an ap­prox­i­mately 10-day mis­sion around the Moon and back to Earth.

The first crewed deep-space flight in over 50 years, Artemis II is ex­pected to send the crew far­ther from Earth than any pre­vi­ous hu­man mis­sion, po­ten­tially break­ing the record of about 248,655 miles (400,171 km) from Earth set by Apollo 13 dur­ing its lu­nar free-re­turn tra­jec­tory. This mile­stone will oc­cur dur­ing the lu­nar flyby phase, when the crew trav­els on a free-re­turn tra­jec­tory around the Moon, which al­lows the space­craft to loop around the Moon and re­turn to Earth with­out en­ter­ing lu­nar or­bit.

During the test flight, NASA will test life-sup­port sys­tems and crit­i­cal op­er­a­tions in deep space, paving the way for fu­ture lu­nar land­ings and Mars ex­plo­ration.

Having received good­byes and well wishes from their fam­i­lies and friends, the crew em­barks on the 20-minute jour­ney to Kennedy’s Launch Pad 39B and their await­ing space­craft.

NASA’s pad res­cue and close­out crew teams have ar­rived at Launch Complex 39B at the agen­cy’s Kennedy Space Center in Florida to en­sure safety and readi­ness dur­ing the crit­i­cal fu­el­ing op­er­a­tions. These spe­cial­ized teams play a vi­tal role in pro­tect­ing per­son­nel and hard­ware through­out the count­down.

The pad res­cue team will be po­si­tioned to re­spond im­me­di­ately in the un­likely event of an emer­gency, en­sur­ing safe evac­u­a­tion pro­ce­dures for pad per­son­nel. The res­cue team is equipped with ad­vanced gear and trained for rapid crew ex­trac­tion, fire sup­pres­sion, and haz­ard mit­i­ga­tion. Their pres­ence en­sures as­tro­naut safety re­mains the top pri­or­ity, pro­vid­ing an all-im­por­tant layer of pro­tec­tion as fu­el­ing op­er­a­tions and sys­tem checks con­tinue.

The closeout crew is re­spon­si­ble for clos­ing the Orion crew mod­ule and launch abort sys­tem hatches, se­cur­ing ac­cess points, ver­i­fy­ing pad con­fig­u­ra­tions, and main­tain­ing the in­tegrity of the launch area dur­ing pro­pel­lant load­ing and sys­tem checks. Their work is crit­i­cal for guar­an­tee­ing a se­cure en­vi­ron­ment for the as­tro­nauts be­fore the launch pad is cleared for liftoff op­er­a­tions.

These teams are es­sen­tial for mit­i­gat­ing risk and sup­port­ing the com­plex chore­og­ra­phy of Artemis II’s prelaunch ac­tiv­i­ties. With both teams in place, Artemis II remains on track for its his­toric mis­sion to send as­tro­nauts around the Moon.

NASA as­tro­nauts Reid Wiseman, com­man­der; Victor Glover, pi­lot; and Christina Koch, mis­sion spe­cial­ist; along with CSA (Canadian Space Agency) as­tro­naut Jeremy Hansen, mis­sion spe­cial­ist, are suit­ing up in­side the Astronaut Crew Quarters of the Neil A. Armstrong Operations and Checkout Building at the agen­cy’s Kennedy Space Center in Florida.

A team of suit tech­ni­cians help the crew put on their Orion Crew Survival System suits, which are each tai­lored for mo­bil­ity and com­fort while en­sur­ing max­i­mum safety dur­ing the dy­namic phases of flight. The bright or­ange space­suits are de­signed to pro­tect them on their jour­ney and fea­ture many im­prove­ments from head to toe to the suits worn on the space shut­tle. NASA reengi­neered many el­e­ments to im­prove safety and range of mo­tion for Artemis as­tro­nauts, and in­stead of the small, medium, and large sizes from the shut­tle era, they are cus­tom fit for each crew mem­ber.

The outer layer is fire-re­sis­tant, and a stronger zip­per al­lows as­tro­nauts to quickly put the suit on. Improved ther­mal man­age­ment will help keep them cool and dry. A lighter, stronger hel­met im­proves com­fort and com­mu­ni­ca­tion, and the gloves are more durable and touch-screen com­pat­i­ble. Better-fitting boots also pro­vide pro­tec­tion in the case of fire and help an as­tro­naut move more swiftly.

The suits’ de­sign and en­gi­neer­ing en­hance­ments pro­vide an ad­di­tional layer of pro­tec­tion for as­tro­nauts and en­sure they re­turn home safely from deep space mis­sions.

During suit-up, teams will check for leaks and en­sure that all con­nect­ing life sup­port sys­tems, in­clud­ing air and power, are op­er­at­ing nom­i­nally ahead of the crew’s ride to NASA Kennedy’s Launch Complex 39B.

With NASA teams now main­tain­ing the liq­uid oxy­gen lev­els in the in­terim cryo­genic propul­sion, all cryo­genic stages of the SLS (Space Launch System) rocket have tran­si­tioned to re­plen­ish mode dur­ing the Artemis II launch count­down. This in­cludes the core stage and SLS up­per stage, en­sur­ing both liq­uid hy­dro­gen and liq­uid oxy­gen tanks re­main at flight-ready lev­els.

Replenish mode is es­sen­tial for main­tain­ing sta­ble pro­pel­lant quan­ti­ties and pres­sure as su­per-cold fu­els nat­u­rally boil off over time. Continuous ad­just­ments keep the rocket fully fu­eled and ready for ig­ni­tion, sup­port­ing the RS-25 en­gines on the core stage and the RL10 en­gine on the SLS up­per stage for their es­sen­tial roles in launch and translu­nar in­jec­tion.

These mile­stones co­in­cide with the Artemis II count­down en­ter­ing a planned 1-hour and 10-minute built-in hold. This sched­uled pause al­lows teams to com­plete cru­cial sys­tem checks, ver­ify launch readi­ness, and ad­dress any last-minute ad­just­ments be­fore pro­ceed­ing to­ward crew ingress and fi­nal fu­el­ing op­er­a­tions.

During this hold, en­gi­neers re­view data from cryo­genic load­ing, propul­sion sys­tems, and com­mu­ni­ca­tions to en­sure all pa­ra­me­ters meet strict safety and per­for­mance cri­te­ria. The hold also pro­vides flex­i­bil­ity for re­solv­ing mi­nor is­sues with­out im­pact­ing the over­all launch time­line.

Once the hold con­cludes, the count­down will re­sume with prepa­ra­tions for as­tro­naut ar­rival at Launch Pad 39B at NASA’s Kennedy Space Center in Florida.

NASA’s Artemis II astronauts received a fi­nal weather brief­ing in­side the Astronaut Crew Quarters of the Neil A. Armstrong Operations and Checkout Building at the agen­cy’s Kennedy Space Center in Florida, as part of prelaunch prepa­ra­tions.

This weather up­date pro­vides as­tro­nauts and mis­sion teams with the lat­est con­di­tions at NASA Kennedy’s Launch Pad 39B, the sur­round­ing re­cov­ery zones, and po­ten­tial abort sites along Artemis II’s flight path. Accurate weather fore­cast­ing is es­sen­tial for pro­tect­ing crew and hard­ware, as even mi­nor changes can im­pact count­down de­ci­sions and flight dy­nam­ics.

NASA as­tro­nauts Reid Wiseman, com­man­der; Vic­tor Glover, pi­lot; and Christina Koch, mis­sion spe­cial­ist; along with CSA (Canadian Space Agency) as­tro­naut Je­remy Hansen, mis­sion spe­cial­ist, were briefed on wind speeds, pre­cip­i­ta­tion, light­ning risk, and sea states for splash­down con­tin­gen­cies, en­sur­ing all safety cri­te­ria are met be­fore pro­ceed­ing with launch op­er­a­tions.

Weather of­fi­cials with NASA and the U. S. Space Force’s Space Launch Delta 45 are track­ing 80% fa­vor­able con­di­tions dur­ing the launch win­dow, with pri­mary con­cerns be­ing the cu­mu­lus cloud rule, flight through pre­cip­i­ta­tion rule, and ground winds.

With the weather brief­ing com­plete, the crew and ground teams re­main aligned and ready to con­tinue to­ward liftoff, keep­ing Artemis II on track for its his­toric mis­sion to send as­tro­nauts around the Moon.

NASA teams also have be­gun liq­uid oxy­gen (LOX) top­ping process for the in­terim cryo­genic propul­sion stage, or SLS (Space Launch System) rocket up­per stage, dur­ing the Artemis II launch count­down. This step fol­lows the fast fill phase and en­sures the liq­uid oxy­gen tank reaches full ca­pac­ity with su­per-cold ox­i­dizer.

Live cov­er­age of Artemis II tank­ing op­er­a­tions con­tin­ues on NASA’s YouTube chan­nel. NASA’s full launch cov­er­age be­gins at 1 p.m. EDT on NASA+, Amazon Prime, and YouTube. You can con­tinue to fol­low the Artemis blog from launch to splash­down for mis­sion up­dates.

Liquid oxy­gen (LOX) fast fill is now com­plete for the SLS (Space Launch System) up­per stage, mark­ing an­other ma­jor mile­stone in tank­ing op­er­a­tions. Teams have con­firmed the up­per stage is in good shape and are pro­ceed­ing with the LOX vent and re­lief test. This step helps ver­ify proper pres­sure reg­u­la­tion and en­sures the sys­tem is ready to tran­si­tion into top­ping and, later, re­plen­ish op­er­a­tions.

NASA teams are now main­tain­ing the liq­uid oxy­gen lev­els in the SLS (Space Launch System) rocket core stage through re­plen­ish mode. This phase fol­lows the com­ple­tion of liq­uid oxy­gen fast fill and top­ping, en­sur­ing the ox­i­dizer re­mains at flight-ready lev­els through­out the fi­nal count­down.

NASA teams are in fast fill of liq­uid oxy­gen (LOX) into the in­terim cryo­genic propul­sion stage as part of the Artemis II launch count­down. This phase rapidly loads the ox­i­dizer af­ter chill­down is com­plete, bring­ing the SLS (Space Launch System) rocket up­per stage closer to full readi­ness for its role in send­ing the Orion space­craft into a high Earth or­bit ahead of a prox­im­ity op­er­a­tions demon­stra­tion test and Orion’s translu­nar in­jec­tion burn.

NASA teams have tran­si­tioned the in­terim cryo­genic propul­sion stage liq­uid hy­dro­gen tank to re­plen­ish mode dur­ing the Artemis II countdown. This phase fol­lows the suc­cess­ful top­ping process and en­sures the tank re­mains at flight-ready lev­els all the way to launch.

NASA teams have be­gun the top­ping phase for the in­terim cryo­genic propul­sion stage liq­uid hy­dro­gen (LH2) tank. This crit­i­cal step oc­curs af­ter suc­cess­ful chill­down and vent-and-re­lief checks, en­sur­ing the tank reaches full ca­pac­ity with su­per-cold liq­uid hy­dro­gen.

Replenish is the fi­nal step in the fu­el­ing process, de­signed to main­tain the cor­rect LH2 lev­els as the su­per-cold pro­pel­lant nat­u­rally boils off over time. This con­tin­u­ous, low-rate flow keeps the tanks topped off and ther­mally sta­ble, en­sur­ing the rocket re­mains fully fu­eled and ready for liftoff.

From chill­down to re­plen­ish, every phase of fu­el­ing is care­fully man­aged to pro­tect hard­ware and guar­an­tee mis­sion suc­cess. With re­plen­ish un­der­way, Artemis II is in its fi­nal stretch to­ward launch and hu­man­i­ty’s next gi­ant leap.

Topping is the process of adding small amounts of LH2 to the tanks af­ter fast fill is com­plete, en­sur­ing they re­main at full ca­pac­ity as the su­per-cold pro­pel­lant nat­u­rally boils off. This step is crit­i­cal for main­tain­ing the pre­cise lev­els needed for launch while keep­ing the sys­tem ther­mally sta­ble.

The Artemis II launch team tran­si­tioned to the fast fill of liq­uid hy­dro­gen (LH2) for the in­terim cryo­genic propul­sion stage, or SLS (Space Launch System) rocket upper stage.

After completing the chill­down phase, this step rapidly loads su­per-cold LH2 into the SLS up­per stage tanks, en­sur­ing the up­per stage is fu­eled and ready to per­form its fun­da­men­tal role of rais­ing the Orion space­craft into a high Earth or­bit ahead of a prox­im­ity op­er­a­tions demon­stra­tion test and Orion’s translu­nar in­jec­tion burn.

Fast fill ac­cel­er­ates the fu­el­ing process while main­tain­ing safety, mark­ing an­other ma­jor mile­stone in the count­down as Artemis II moves closer to liftoff.

The Artemis II launch team has be­gun the liq­uid hy­dro­gen chill­down for the in­terim cryo­genic propul­sion stage, or SLS (Space Launch System) rocket upper stage.

This process grad­u­ally cools the in­terim cryo­genic propul­sion stage fuel lines and com­po­nents to cryo­genic tem­per­a­tures us­ing su­per-cold liq­uid hy­dro­gen. The chill­down step is es­sen­tial to pre­vent ther­mal shock and en­sure the stage is prop­erly con­di­tioned for full pro­pel­lant load­ing. By sta­bi­liz­ing the sys­tem at these ex­treme tem­per­a­tures, en­gi­neers guar­an­tee safe and ef­fi­cient fu­el­ing for the up­per stage that will help po­si­tion Orion into high Earth or­bit for its jour­ney to­ward the Moon.

NASA as­tro­nauts Reid Wiseman, Victor Glover, and Christina Koch, along with CSA (Canadian Space Agency) as­tro­naut Je­remy Hansen have of­fi­cially be­gun their launch day with a sched­uled wake-up call at 9:25 a.m., mark­ing the start of their fi­nal prepa­ra­tions for the his­toric Artemis II mis­sion around the Moon.

The Artemis II launch team tran­si­tioned to the fast fill of liq­uid hy­dro­gen (LH2) into the SLS (Space Launch System) rocket core stage.

The cost of build­ing soft­ware has dras­ti­cally de­creased. We re­cently re­built Next.js in one week us­ing AI cod­ing agents. But for the past two months our agents have been work­ing on an even more am­bi­tious pro­ject: re­build­ing the WordPress open source pro­ject from the ground up.

WordPress pow­ers over 40% of the Internet. It is a mas­sive suc­cess that has en­abled any­one to be a pub­lisher, and cre­ated a global com­mu­nity of WordPress de­vel­op­ers. But the WordPress open source pro­ject will be 24 years old this year. Hosting a web­site has changed dra­mat­i­cally dur­ing that time. When WordPress was born, AWS EC2 did­n’t ex­ist. In the in­ter­ven­ing years, that task has gone from rent­ing vir­tual pri­vate servers, to up­load­ing a JavaScript bun­dle to a glob­ally dis­trib­uted net­work at vir­tu­ally no cost. It’s time to up­grade the most pop­u­lar CMS on the Internet to take ad­van­tage of this change.

Our name for this new CMS is EmDash. We think of it as the spir­i­tual suc­ces­sor to WordPress. It’s writ­ten en­tirely in TypeScript. It is server­less, but you can run it on your own hard­ware or any plat­form you choose. Plugins are se­curely sand­boxed and can run in their own iso­late, via Dynamic Workers, solv­ing the fun­da­men­tal se­cu­rity prob­lem with the WordPress plu­gin ar­chi­tec­ture. And un­der the hood, EmDash is pow­ered by Astro, the fastest web frame­work for con­tent-dri­ven web­sites.

EmDash is fully open source, MIT li­censed, and avail­able on GitHub. While EmDash aims to be com­pat­i­ble with WordPress func­tion­al­ity, no WordPress code was used to cre­ate EmDash. That al­lows us to li­cense the open source pro­ject un­der the more per­mis­sive MIT li­cense. We hope that al­lows more de­vel­op­ers to adapt, ex­tend, and par­tic­i­pate in EmDash’s de­vel­op­ment.

You can de­ploy the EmDash v0.1.0 pre­view to your own Cloudflare ac­count, or to any Node.js server to­day as part of our early de­vel­oper beta:

Or you can try out the ad­min in­ter­face here in the EmDash Playground:

The story of WordPress is a tri­umph of open source that en­abled pub­lish­ing at a scale never be­fore seen. Few pro­jects have had the same recog­nis­able im­pact on the gen­er­a­tion raised on the Internet. The con­trib­u­tors to WordPress’s core, and its many thou­sands of plu­gin and theme de­vel­op­ers have built a plat­form that de­moc­ra­tised pub­lish­ing for mil­lions; many lives and liveli­hoods be­ing trans­formed by this ubiq­ui­tous soft­ware.

There will al­ways be a place for WordPress, but there is also a lot more space for the world of con­tent pub­lish­ing to grow. A decade ago, peo­ple pick­ing up a key­board uni­ver­sally learned to pub­lish their blogs with WordPress. Today it’s just as likely that per­son picks up Astro, or an­other TypeScript frame­work to learn and build with. The ecosys­tem needs an op­tion that em­pow­ers a wide au­di­ence, in the same way it needed WordPress 23 years ago.

EmDash is com­mit­ted to build­ing on what WordPress cre­ated: an open source pub­lish­ing stack that any­one can in­stall and use at lit­tle cost, while fix­ing the core prob­lems that WordPress can­not solve.

WordPress’ plu­gin ar­chi­tec­ture is fun­da­men­tally in­se­cure. 96% of se­cu­rity is­sues for WordPress sites orig­i­nate in plu­g­ins. In 2025, more high sever­ity vul­ner­a­bil­i­ties were found in the WordPress ecosys­tem than the pre­vi­ous two years com­bined.

Why, af­ter over two decades, is WordPress plu­gin se­cu­rity so prob­lem­atic?

A WordPress plu­gin is a PHP script that hooks di­rectly into WordPress to add or mod­ify func­tion­al­ity. There is no iso­la­tion: a WordPress plu­gin has di­rect ac­cess to the WordPress site’s data­base and filesys­tem. When you in­stall a WordPress plu­gin, you are trust­ing it with ac­cess to nearly every­thing, and trust­ing it to han­dle every ma­li­cious in­put or edge case per­fectly.

EmDash solves this. In EmDash, each plu­gin runs in its own iso­lated sand­box: a Dynamic Worker. Rather than giv­ing di­rect ac­cess to un­der­ly­ing data, EmDash pro­vides the plu­gin with ca­pa­bil­i­ties via bind­ings, based on what the plu­gin ex­plic­itly de­clares that it needs in its man­i­fest. This se­cu­rity model has a strict guar­an­tee: an EmDash plu­gin can only per­form the ac­tions ex­plic­itly de­clared in its man­i­fest. You can know and trust up­front, be­fore in­stalling a plu­gin, ex­actly what you are grant­ing it per­mis­sion to do, sim­i­lar to go­ing through an OAuth flow and grant­ing a 3rd party app a spe­cific set of scoped per­mis­sions.

For ex­am­ple, a plu­gin that sends an email af­ter a con­tent item gets saved looks like this:

im­port { de­fine­Plu­gin } from “emdash”;

ex­port de­fault () =>

de­fine­Plu­gin({

id: “notify-on-publish”,

ver­sion: “1.0.0”,

ca­pa­bil­i­ties: [“read:content”, “email:send”],

hooks: {

“content:afterSave”: async (event, ctx) => {

if (event.collection !== “posts” || event.con­tent.sta­tus !== “published”) re­turn;

await ctx.email!.send({

to: “[email protected]”,

sub­ject: `New post pub­lished: ${event.content.title}`,

text: `“${event.content.title}” is now live.`,

ctx.log.info(`No­ti­fied ed­i­tors about ${event.content.id}`);

This plu­gin ex­plic­itly re­quests two ca­pa­bil­i­ties: con­tent:af­ter­Save to hook into the con­tent life­cy­cle, and email:send to ac­cess the ctx.email func­tion. It is im­pos­si­ble for the plu­gin to do any­thing other than use these ca­pa­bil­i­ties. It has no ex­ter­nal net­work ac­cess. If it does need net­work ac­cess, it can spec­ify the ex­act host­name it needs to talk to, as part of its de­f­i­n­i­tion, and be granted only the abil­ity to com­mu­ni­cate with a par­tic­u­lar host­name.

And in all cases, be­cause the plug­in’s needs are de­clared sta­t­i­cally, up­front, it can al­ways be clear ex­actly what the plu­gin is ask­ing for per­mis­sion to be able to do, at in­stall time. A plat­form or ad­min­is­tra­tor could de­fine rules for what plu­g­ins are or aren’t al­lowed to be in­stalled by cer­tain groups of users, based on what per­mis­sions they re­quest, rather than an al­lowlist of ap­proved or safe plu­g­ins.

WordPress plu­gin se­cu­rity is such a real risk that WordPress.org man­u­ally re­views and ap­proves each plu­gin in its mar­ket­place. At the time of writ­ing, that re­view queue is over 800 plu­g­ins long, and takes at least two weeks to tra­verse. The vul­ner­a­bil­ity sur­face area of WordPress plu­g­ins is so wide that in prac­tice, all par­ties rely on mar­ket­place rep­u­ta­tion, rat­ings and re­views. And be­cause WordPress plu­g­ins run in the same ex­e­cu­tion con­text as WordPress it­self and are so deeply in­ter­twined with WordPress code, some ar­gue they must carry for­ward WordPress’ GPL li­cense.

These re­al­i­ties com­bine to cre­ate a chill­ing ef­fect on de­vel­op­ers build­ing plu­g­ins, and on plat­forms host­ing WordPress sites.

Plugin se­cu­rity is the root of this prob­lem. Marketplace busi­nesses pro­vide trust when par­ties oth­er­wise can­not eas­ily trust each other. In the case of the WordPress mar­ket­place, the plu­gin se­cu­rity risk is so large and prob­a­ble that many of your cus­tomers can only rea­son­ably trust your plu­gin via the mar­ket­place. But in or­der to be part of the mar­ket­place your code must be li­censed in a way that forces you to give it away for free every­where other than that mar­ket­place. You are locked in.

EmDash plu­g­ins have two im­por­tant prop­er­ties that mit­i­gate this mar­ket­place lock-in:

Plugins can have any li­cense: they run in­de­pen­dently of EmDash and share no code. It’s the plu­gin au­thor’s choice. Plugin code runs in­de­pen­dently in a se­cure sand­box: a plu­gin can be pro­vided to an EmDash site, and trusted, with­out the EmDash site ever see­ing the code.

The first part is straight­for­ward — as the plu­gin au­thor, you choose what li­cense you want. The same way you can when pub­lish­ing to NPM, PyPi, Packagist or any other reg­istry. It’s an open ecosys­tem for all, and up to the com­mu­nity, not the EmDash pro­ject, what li­cense you use for plu­g­ins and themes.

The sec­ond part is where EmDash’s plu­gin ar­chi­tec­ture breaks free of the cen­tral­ized mar­ket­place.

Developers need to rely on a third party mar­ket­place hav­ing vet­ted the plu­gin far less to be able to make de­ci­sions about whether to use or trust it. Consider the ex­am­ple plu­gin above that sends emails af­ter con­tent is saved; the plu­gin de­clares three things:

It only runs on the con­tent:af­ter­Save hookIt has the read:con­tent ca­pa­bil­i­tyIt has the email:send ca­pa­bil­ity

The plu­gin can have tens of thou­sands of lines of code in it, but un­like a WordPress plu­gin that has ac­cess to every­thing and can talk to the pub­lic Internet, the per­son adding the plu­gin knows ex­actly what ac­cess they are grant­ing to it. The clearly de­fined bound­aries al­low you to make in­formed de­ci­sions about se­cu­rity risks and to zoom in on more spe­cific risks that re­late di­rectly to the ca­pa­bil­i­ties the plu­gin is given.

The more that both sites and plat­forms can trust the se­cu­rity model to pro­vide con­straints, the more that sites and plat­forms can trust plu­g­ins, and break free of cen­tral­ized con­trol of mar­ket­places and rep­u­ta­tion. Put an­other way: if you trust that food safety is en­forced in your city, you’ll be ad­ven­tur­ous and try new places. If you can’t trust that there might be a sta­ple in your soup, you’ll be con­sult­ing Google be­fore every new place you try, and it’s harder for every­one to open new restau­rants.

The busi­ness model of the web is at risk, par­tic­u­larly for con­tent cre­ators and pub­lish­ers. The old way of mak­ing con­tent widely ac­ces­si­ble, al­low­ing all clients free ac­cess in ex­change for traf­fic, breaks when there is no hu­man look­ing at a site to ad­ver­tise to, and the client is in­stead their agent ac­cess­ing the web on their be­half. Creators need ways to con­tinue to make money in this new world of agents, and to build new kinds of web­sites that serve what peo­ple’s agents need and will pay for. Decades ago a new wave of cre­ators cre­ated web­sites that be­came great busi­nesses (often us­ing WordPress to power them) and a sim­i­lar op­por­tu­nity ex­ists to­day.

x402 is an open, neu­tral stan­dard for Internet-native pay­ments. It lets any­one on the Internet eas­ily charge, and any client pay on-de­mand, on a pay-per-use ba­sis. A client, such as an agent, sends a HTTP re­quest and re­ceives a HTTP 402 Payment Required sta­tus code. In re­sponse, the client pays for ac­cess on-de­mand, and the server can let the client through to the re­quested con­tent.

EmDash has built-in sup­port for x402. This means any­one with an EmDash site can charge for ac­cess to their con­tent with­out re­quir­ing sub­scrip­tions and with zero en­gi­neer­ing work. All you need to do is con­fig­ure which con­tent should re­quire pay­ment, set how much to charge, and pro­vide a Wallet ad­dress. The re­quest/​re­sponse flow ends up look­ing like this:

Every EmDash site has a built-in busi­ness model for the AI era.

WordPress is not server­less: it re­quires pro­vi­sion­ing and man­ag­ing servers, scal­ing them up and down like a tra­di­tional web ap­pli­ca­tion. To max­i­mize per­for­mance, and to be able to han­dle traf­fic spikes, there’s no avoid­ing the need to pre-pro­vi­sion in­stances and run some amount of idle com­pute, or share re­sources in ways that limit per­for­mance. This is par­tic­u­larly true for sites with con­tent that must be server ren­dered and can­not be cached.

EmDash is dif­fer­ent: it’s built to run on server­less plat­forms, and make the most out of the v8 iso­late ar­chi­tec­ture of Cloudflare’s open source run­time work­erd. On an in­com­ing re­quest, the Workers run­time in­stantly spins up an iso­late to ex­e­cute code and serve a re­sponse. It scales back down to zero if there are no re­quests. And it only bills for CPU time (time spent do­ing ac­tual work).

You can run EmDash any­where, on any Node.js server — but on Cloudflare you can run mil­lions of in­stances of EmDash us­ing Cloudflare for Platforms that each in­stantly scale fully to zero or up to as many RPS as you need to han­dle, us­ing the ex­act same net­work and run­time that the biggest web­sites in the world rely on.

Beyond cost op­ti­miza­tions and per­for­mance ben­e­fits, we’ve bet on this ar­chi­tec­ture at Cloudflare in part be­cause we be­lieve in hav­ing low cost and free tiers, and that every­one should be able to build web­sites that scale. We’re ex­cited to help plat­forms ex­tend the ben­e­fits of this ar­chi­tec­ture to their own cus­tomers, both big and small.

EmDash is pow­ered by Astro, the web frame­work for con­tent-dri­ven web­sites. To cre­ate an EmDash theme, you cre­ate an Astro pro­ject that in­cludes:

A seed file: JSON that tells the CMS what con­tent types and fields to cre­ate

This makes cre­at­ing themes fa­mil­iar to fron­tend de­vel­op­ers who are in­creas­ingly choos­ing Astro, and to LLMs which are al­ready trained on Astro.

WordPress themes, though in­cred­i­bly flex­i­ble, op­er­ate with a lot of the same se­cu­rity risks as plu­g­ins, and the more pop­u­lar and com­mon­place your theme, the more of a tar­get it is. Themes run through in­te­grat­ing with func­tions.php which is an all-en­com­pass­ing ex­e­cu­tion en­vi­ron­ment, en­abling your theme to be both in­cred­i­bly pow­er­ful and po­ten­tially dan­ger­ous. EmDash themes, as with dy­namic plu­g­ins, turns this ex­pec­ta­tion on its head. Your theme can never per­form data­base op­er­a­tions.

The least fun part about work­ing with any CMS is do­ing the rote mi­gra­tion of con­tent: find­ing and re­plac­ing strings, mi­grat­ing cus­tom fields from one for­mat to an­other, re­nam­ing, re­order­ing and mov­ing things around. This is ei­ther bor­ing repet­i­tive work or re­quires one-off scripts and  “single-use” plu­g­ins and tools that are usu­ally nei­ther fun to write nor to use.

EmDash is de­signed to be man­aged pro­gram­mat­i­cally by your AI agents. It pro­vides the con­text and the tools that your agents need, in­clud­ing:

Agent Skills: Each EmDash in­stance in­cludes Agent Skills that de­scribe to your agent the ca­pa­bil­i­ties EmDash can pro­vide to plu­g­ins, the hooks that can trig­ger plu­g­ins, guid­ance on how to struc­ture a plu­gin, and even how to port legacy WordPress themes to EmDash na­tively. When you give an agent an EmDash code­base, EmDash pro­vides every­thing the agent needs to be able to cus­tomize your site in the way you need. EmDash CLI: The EmDash CLI en­ables your agent to in­ter­act pro­gram­mat­i­cally with your lo­cal or re­mote in­stance of EmDash. You can up­load me­dia, search for con­tent, cre­ate and man­age schemas, and do the same set of things you can do in the Admin UI.Built-in MCP Server: Every EmDash in­stance pro­vides its own re­mote Model Context Protocol (MCP) server, al­low­ing you to do the same set of things you can do in the Admin UI.

EmDash uses passkey-based au­then­ti­ca­tion by de­fault, mean­ing there are no pass­words to leak and no brute-force vec­tors to de­fend against. User man­age­ment in­cludes fa­mil­iar role-based ac­cess con­trol out of the box: ad­min­is­tra­tors, ed­i­tors, au­thors, and con­trib­u­tors, each scoped strictly to the ac­tions they need. Authentication is plug­gable, so you can set EmDash up to work with your SSO provider, and au­to­mat­i­cally pro­vi­sion ac­cess based on IdP meta­data.

You can im­port an ex­ist­ing WordPress site by ei­ther go­ing to WordPress ad­min and ex­port­ing a WXR file, or by in­stalling the EmDash Exporter plu­gin on a WordPress site, which con­fig­ures a se­cure end­point that is only ex­posed to you, and pro­tected by a WordPress Application Password you con­trol. Migrating con­tent takes just a few min­utes, and au­to­mat­i­cally works to bring any at­tached me­dia into EmDash’s me­dia li­brary.

Creating any cus­tom con­tent types on WordPress that are not a Post or a Page has meant in­stalling heavy plu­g­ins like Advanced Custom Fields, and squeez­ing the re­sult into a crowded WordPress posts table. EmDash does things dif­fer­ently: you can de­fine a schema di­rectly in the ad­min panel, which will cre­ate en­tirely new EmDash col­lec­tions for you, sep­a­rately or­dered in the data­base. On im­port, you can use the same ca­pa­bil­i­ties to take any cus­tom post types from WordPress, and cre­ate an EmDash con­tent type from it.

For be­spoke blocks, you can use the EmDash Block Kit Agent Skill to in­struct your agent of choice and build them for EmDash.

EmDash is v0.1.0 pre­view, and we’d love you to try it, give feed­back, and we wel­come con­tri­bu­tions to the EmDash GitHub repos­i­tory.

If you’re just play­ing around and want to first un­der­stand what’s pos­si­ble — try out the ad­min in­ter­face in the EmDash Playground.

To cre­ate a new EmDash site lo­cally, via the CLI, run:

Or you can do the same via the Cloudflare dash­board be­low:

We’re ex­cited to see what you build, and if you’re ac­tive in the WordPress com­mu­nity, as a host­ing plat­form, a plu­gin or theme au­thor, or oth­er­wise — we’d love to hear from you. Email us at [email protected], and tell us what you’d like to see from the EmDash pro­ject.

If you want to stay up to date with ma­jor EmDash de­vel­op­ments, you can leave your email ad­dress here.

Today Raspberry Pi an­nounced more price in­creases for all Pis with LPDDR4 RAM, along­side a ‘right-sized’ 3GB RAM Pi 4 for $83.75.

The price in­creases bring the 16GB Pi 5 up to $299.99.

Despite to­day’s date, this is not a joke.

I pub­lished a video go­ing over the state of the hob­by­ist ‘high end SBC’ mar­ket (4/8/16 GB mod­els in the cur­rent gen­er­a­tion), which I’ll em­bed be­low:

But if you’d like the tl;dr:

Unless the DRAM pric­ing sit­u­a­tion changes rad­i­cally, I think the hob­by­ist SBC mar­ket is dy­ing—or at least on life sup­port. And I don’t just mean Raspberry Pis, but all SBC ven­dors. LPDDR chips now ac­count for the ma­jor­ity of board cost from the ven­dors I’ve checked with.

Besides caus­ing a rad­i­cal re­duc­tion in new boards launched (Radxa seems to be the only ven­dor that had some ca­dence last year), the price in­creases for boards with greater than 4 GB of RAM have put those boards out of the reach of most hob­by­ists.

Even mini PCs, which for a time were a great deal, have risen to $250+ for 8 GB mod­els. Used PC are also more ex­pen­sive, es­pe­cially with more than 4 GB of RAM.

I de­sign most of my pro­jects so they can be repli­cated for less than $100. Learning is eas­ier on cheaper parts you won’t fret over too much when you break them. With prices go­ing up, this lim­its the types of pro­jects I take on.

I’m work­ing more with older SBCs and mi­cro­con­trollers now, and I think that’s the di­rec­tion many in the hob­by­ist space are go­ing.

Maybe, as Eben Upton says in Raspberry Pi’s post,

mem­ory prices won’t re­main at their cur­rent very high level in­def­i­nitely; the cir­cum­stances in which we find our­selves are chal­leng­ing, but in the fu­ture they will abate.

But I’m not sure how long we’ll have to wait, or if a hob­by­ist SBC mar­ket will ex­ist by the time the bub­ble bursts.

Lucky for Raspberry Pi, they have a thriv­ing mi­cro­con­troller ecosys­tem and in­dus­trial base to keep them go­ing. I fear smaller ven­dors won’t be able to go on like this for­ever.

… is what I’m read­ing far too of­ten! Some of you are los­ing faith!

A grow­ing sen­ti­ment amongst my peers — those who haven’t al­ready re­signed to an NPC ca­reer path† — is that blog­ging is over. Coding is cooked. What’s the point of shar­ing in­sights and ex­per­tise when the Cognitive Dark Forest will feed on our hu­man­ity?

Before I’m dis­missed as an ill-in­formed hater please note: I’ve done my re­search.

† To be fair it’s a valid choice in this econ­omy. Clock in, slop around, clock out. Why not?

Star Trek’s cap­tain Kirk lean­ing into a com­puter cast in shadow look­ing con­tem­pla­tive.

It’s never been more im­por­tant to blog. There has never been a bet­ter time to blog. I will tell you why. We’re be­ing starved for hu­man con­ver­sa­tion and au­then­tic voices. What’s more: every­one is try­ing to take your voice away. Do not opt-out of us­ing it your­self.

First let’s ac­cept the re­al­i­ties. The gi­ant pla­gia­rism ma­chines have al­ready stolen every­thing. Copyright is dead. Licenses are washed away in clean rooms. Mass sur­veil­lance and track­ing are a fea­ture, pri­vacy is a bug. Everything is an “algorithm” op­ti­mised to ex­ploit.

How can we pos­si­bly com­bat that?

From a purely self­ish per­spec­tive it’s never been eas­ier to stand out and as­sert your­self as an au­thor­ity. When every­one is de­fer­ring to the big bull­shit­ter in the cloud your orig­i­nal thoughts are in­valu­able. Your brain is your biggest as­set. Share it with oth­ers for mu­tual ben­e­fit.

I find writ­ing stuff down im­proves my mem­ory and hard­ens my re­solve. I bet that’s true for you too. It’s part rote learn­ing part rub­ber­duck­ing†. Writing pub­licly in blog form forces me to ques­tion as­sump­tions. Even when re­search fails me Cunningham’s Law saves me.

† Some will claim writ­ing into a pre­dic­tive chat box helps too, and sure, they’re ab­solutely right!

Blogging makes you a bet­ter pro­fes­sional. No mat­ter how small your au­di­ence, some­one will even­tu­ally stum­ble upon your blog and it will un­block their path.

Don’t ac­cept a fate be­ing forced upon you.

The AI in­dus­try is 99% hype; a bil­lion dol­lar in­dus­trial com­plex to put a price tag on cre­ation. At this point if you be­lieve AI is ‘just a tool’ you’re wil­fully ig­nor­ing the harm. (Regardless, why do I keep be­ing told it’s an ‘extreme’ stance if I de­cide not to buy some­thing?)

The 1% util­ity AI has is over­shad­owed by the over­whelm­ing medioc­racy it re­gur­gi­tates.

We’re say­ing good­bye to Sora. To every­one who cre­ated with Sora, shared it, and built com­mu­nity around it: thank you. What you made with Sora mat­tered, and we know this news is dis­ap­point­ing.

Is there any­thing, in the en­tire recorded his­tory of hu­man cre­ation, that could have pos­si­bly mat­tered less than the flat­u­lence Sora pro­duced? NFTs had more value.

I’m not pro­tec­tive over the word “art”. Generative AI is art. It’s ir­re­deemably shit art; end of con­ver­sa­tion. A child’s crayon doo­dle is also lack­ing re­fined artistry but we hang it on our fridge be­cause a hu­man made it and that mat­ters. We care and car­ing has a pos­i­tive ef­fect on our lives. When you pass hu­man cre­ativ­ity through the slop wringer, or just prompt an in­can­ta­tion, the re­sult is con­tin­voucly morged; a va­pid mock­ery of the in­put. The garbage out no longer mat­ters, no­body cares, no­body ben­e­fits.

I for­got where I was go­ing with this… oh right: don’t re­sign your­self to the deskilling of our craft. You should keep blog­ging! Take pride in your abil­ity and unique voice. But please don’t des­e­crate your­self with slop.

A di­sheveled Oliver Twist looks up plead­ingly hold­ing out an empty bowl.

The only win­ning move is not to play.

We’ve got­ten too com­fort­able with the con­ve­nience of Big Tech. We do not have to con­tinue play­ing their game. Don’t buy the nar­ra­tives they’re sell­ing.

The AI in­dus­try is built on the preda­tory busi­ness model of casi­nos. Except they’ve for­get the house is sup­posed to win. One up­side of this loom­ing eco­nomic and in­tel­lec­tual de­pres­sion is that the me­dia is be­gin­ning to recog­nise gate keep­ers are no longer the hand that feeds them. Big Tech is not the web. You don’t have to use it nor sup­port it. Blog for the old web, the open web, the in­die web — the web you want to see.

And if you think I’m be­ing dra­matic and I’ve up­set your new toys, you’re wel­come to be left be­hind in the mi­as­matic dystopia these tech­no­facists are rac­ing to build.

Go for launch! New time 6.35pm ETWhat to know about the space­craft­First pho­tos of Artemis II crew in their space suitsWho is on the Artemis II crewHow the launch is ex­pected to un­fold

Show key events on­ly­Please turn on JavaScript to use this fea­ture

We’re clos­ing our live blog of the launch of Artemis II now af­ter watch­ing the space rock­et’s spec­tac­u­lar launch into a clear blue Florida sky from the Kennedy Space Center.

Four as­tro­nauts, Americans Reid Wiseman, Victor Glover and Christina Koch, plus Jeremy Hansen from the Canadian Space Agency, are on their way to the moon af­ter lift­ing off at 6.35pm from launch­pad 39B.

Their 10-day lu­nar flyby is the first crewed mis­sion to the moon in more than half a cen­tury. No other hu­mans have trav­eled be­yond lower Earth or­bit since Apollo 17 in December 1972.

Artemis II is a test flight de­signed to eval­u­ate the Orion crew cap­sule and es­sen­tial life sup­port and med­ical sys­tems ahead of fu­ture Artemis mis­sions, in­clud­ing the next moon land­ing sched­uled for Artemis IV in 2028.

Thank you for fol­low­ing the launch with us, and stick with us for news of the mis­sion and cov­er­age of the Artemis II crew’s splash­down in the Pacific Ocean in 10 days’ time.

Officials in Florida’s space coast cities, in­clud­ing Cape Canaveral, Titusville, and Cocoa Beach, said they were ex­pect­ing up to 400,000 spec­ta­tors to fill beaches and cause­ways. As early as first light, shortly be­fore 7am on Wednesday, dozens of cars were al­ready parked along the wa­ter­front in Titusville, which bills it­self as “the gate­way to space and na­ture”.Spec­ta­tors se­cure a van­tage spot for the Artemis II launch at Space View Park, Titusville, Florida, on Wednesday. Photograph: Marco Bello/ReutersThe city has a di­rect view across the Indian river to launch­pad 39B, and the crowds there are a re­minder of the Apollo era of the 1960s and 70s when mil­lions packed in to watch the first moon mis­sions.“There’s three en­try ways to the Kennedy Space Center and two of them go through the city,” Andrew Connors, the mayor of Titusville, told me in an in­ter­view last week.An in­flux of hun­dreds of thou­sands for Artemis II will bring a wel­come fi­nan­cial wind­fall, but Connors is also a lit­tle ap­pre­hen­sive.“It’s pretty crazy to think about it be­cause we’re a city of 51,000,” he said.“All the bridges fill up re­ally quickly and I’m sure the main route through will be a park­ing lot, but our po­lice have been do­ing this a lot of times. It’s some­thing re­ally spe­cial.”Read more from the Titusville mayor, and other space coast fig­ures, here:Florida space coast cities abuzz be­fore Nasa’s Artemis launch: ‘At the doorstep of the fu­ture’

With Orion now or­bit­ing Earth, a lit­tle more than half an hour into flight af­ter a spec­tac­u­lar and flaw­less lift-off from Florida’s Kennedy Space Center, mis­sion man­agers on the ground are as­sess­ing data. Flight con­trollers in Houston have con­firmed that all four so­lar ar­rays were de­ployed suc­cess­fully.Nasa lead­ers, no doubt beam­ing with pride, will con­duct a post-launch press con­fer­ence sched­uled for 9pm ET. Our blog will have closed by then, but the Guardian will con­tinue to bring you news as the rest of the 10-day Artemis II mis­sion un­folds.

Jared Isaacman, the Nasa ad­min­is­tra­tor, spoke about the Artemis II launch on Nasa TV.“It’s the open­ing act, the test mis­sion,” for the Orion space­craft, he said.“No hu­mans have ever flown on this. We’re putting it through its paces to make sure it’s OK. It’s go­ing to set up sub­se­quent mis­sions [and] a golden age of sci­ence and dis­cov­ery.”Isaac­man, a bil­lion­aire pri­vate as­tro­naut and Donald Trump’s pick to lead the agency, who was con­firmed ear­lier this year, was asked what his fa­vorite mo­ment of the mis­sion would be.“Af­ter ig­ni­tion, the mo­ment I’m most ex­cited for is splash­down,” he said.“The take­away is gain­ing ex­tra com­fort in the Orion space­craft. It’s new ter­ri­tory for us. SLS plus Orion is every­thing. On this one we want to make sure we do this in as safe a way as we can.”

Inside the Orion cap­sule, as­tro­nauts Reid Wiseman, Victor Glover, Christina Koch and Jeremy Hansen have raised their vi­sors and are im­me­di­ately com­menc­ing tasks to as­sess how the space­craft han­dled the 17,500mph as­cent to or­bit. Deployment of the so­lar ar­ray wings, which will pro­vide Orion with con­tin­u­ous elec­tri­cal power through­out its lu­nar jour­ney, is about to be­gin.

Artemis II is now in Earth’s or­bit. The two solid rocket boost­ers of the Space Launch System have sep­a­rated and are float­ing back down to the Atlantic for re­cov­ery. The space­craft will or­bit Earth un­til flight day two (Thursday) when the translu­nar in­jec­tion burn will take place and sent it on the rest of its 240,000-mile jour­ney to the moon.

Nasa launched Artemis II on a his­toric crewed mis­sion to the moon. The 10-day test flight, which will not land on the moon, is a mis­sion packed with mile­stones. The mis­sion in­cludes the first woman and first per­son of color to fly into cis­lu­nar space, the area be­tween Earth’s or­bit and the moon.Artemis II’s Orion space cap­sule could fly them far­ther from Earth than any hu­man be­ing be­fore them.

Mission man­agers have an­nounced they are work­ing a few is­sues that will de­lay tonight’s Artemis II launch from its orig­i­nal 6.24pm ET time. Launch di­rec­tor Charlie Blackwell-Thompson says the rec­om­men­da­tion is still to launch at some point, but we don’t yet know what new time might be pro­vided.

Use this to de­tect changes in like­li­hoods of events, for in­stance, to iso­late a com­mit where a slightly flaky test be­came very flaky.

You don’t need to know the like­li­hoods (although you can pro­vide pri­ors), just that some­thing has changed at some point in some di­rec­tion

git_bayesect uses Bayesian in­fer­ence to iden­tify the com­mit in­tro­duc­ing a change, with com­mit se­lec­tion per­formed via greedy min­imi­sa­tion of ex­pected en­tropy, and us­ing a Beta-Bernoulli con­ju­gacy trick while cal­cu­lat­ing pos­te­rior prob­a­bil­i­ties to make han­dling un­known fail­ure rates tractable.

See https://​hauntsan­inja.github.io/​git_bayesect.html for a write up.

Record an ob­ser­va­tion on the cur­rent com­mit:

Check the over­all sta­tus of the bi­sec­tion:

Set the prior for a given com­mit:

Set prior for all com­mits based on file­names:

Set prior for all com­mits based on the text in the com­mit mes­sage + diff:

Get a log of com­mands to let you re­con­struct the state:

Run the bi­sec­tion au­to­mat­i­cally us­ing a com­mand to make ob­ser­va­tions:

Checkout the best com­m­mit to test:

This repos­i­tory con­tains a lit­tle demo, in case you’d like to play around:

Advisory: FreeBSD-SA-26:08.rpcsec_gss

CVE: CVE-2026-4747

Affected: FreeBSD 13.5 (Tested on: FreeBSD 14.4-RELEASE amd64 (GENERIC ker­nel, no KASLR)

Attack sur­face: NFS server with kgss­api.ko loaded (port 2049/TCP)

In sys/​rpc/​rpc­sec_gss/​svc_r­pc­sec_gss.c, the func­tion svc_r­pc_gss_­val­i­date() re­con­structs an RPC header into a 128-byte stack buffer (rpchdr[]) for GSS-API sig­na­ture ver­i­fi­ca­tion. It first writes 32 bytes of fixed RPC header fields, then copies the en­tire RPCSEC_GSS cre­den­tial body (oa_length bytes) into the re­main­ing space — with­out check­ing that oa_length fits.

sta­tic bool_t

svc_r­pc_gss_­val­i­date(struct svc_r­pc_gss_­client *client,

struct rpc_msg *msg, gss_qop_t *qop, rpc_gss_proc_t gcproc)

in­t32_t rpchdr[128 / sizeof(in­t32_t)]; // 128 bytes on stack

in­t32_t *buf;

mem­set(rpchdr, 0, sizeof(rpchdr));

// Write 8 fixed-size RPC header fields (32 bytes to­tal)

buf = rpchdr;

IXDR_PUT_LONG(buf, msg->rm_xid);

IXDR_PUT_ENUM(buf, msg->rm_di­rec­tion);

IXDR_PUT_LONG(buf, msg->rm_­call.cb_r­pcvers);

IXDR_PUT_LONG(buf, msg->rm_­call.cb_prog);

IXDR_PUT_LONG(buf, msg->rm_­call.cb_vers);

IXDR_PUT_LONG(buf, msg->rm_­call.cb_proc);

oa = &msg->rm_call.cb_cred;

IXDR_PUT_ENUM(buf, oa->oa_fla­vor);

IXDR_PUT_LONG(buf, oa->oa_length);

if (oa->oa_length) {

// BUG: No bounds check on oa_length!

// After 32 bytes of header, only 96 bytes re­main in rpchdr.

// If oa_length > 96, this over­flows past rpchdr into:

// lo­cal vari­ables → saved callee-saved reg­is­ters → re­turn ad­dress

mem­cpy((cad­dr_t)buf, oa->oa_base, oa->oa_length);

buf += RNDUP(oa->oa_length) / sizeof(in­t32_t);

// gss_ver­i­fy_mic() called af­ter — but over­flow al­ready hap­pened

The buffer has only 128 - 32 = 96 bytes of space for the cre­den­tial body. Any cre­den­tial larger than 96 bytes over­flows the stack buffer.

The patch adds a sin­gle bounds check be­fore the copy:

oa = &msg->rm_call.cb_cred;

if (oa->oa_length > sizeof(rpchdr) - 8 * BYTES_PER_XDR_UNIT) {

rpc_gss_log_de­bug(“auth length %d ex­ceeds max­i­mum”, oa->oa_length);

client->cl_s­tate = CLIENT_STALE;

re­turn (FALSE);

svc_r­pc_gss_­val­i­date:

push rbp

mov rbp, rsp

push r15  ; saved at [rbp-8]

push r14  ; saved at [rbp-16]

push r13  ; saved at [rbp-24]

push r12  ; saved at [rbp-32]

push rbx  ; saved at [rbp-40]

sub rsp, 0xb8  ; 184 bytes of lo­cal space

The rpchdr ar­ray is at [rbp-0xc0] (192 bytes be­low rbp). The mem­cpy writes to rpchdr + 32 = [rbp-0xa0]. The saved reg­is­ters and re­turn ad­dress are above rpchdr on the stack:

However, these are the off­sets for a cre­den­tial body that starts im­me­di­ately. In prac­tice, the cre­den­tial body be­gins with a GSS header (version, pro­ce­dure, se­quence, ser­vice) plus a con­text han­dle. With a 16-byte han­dle, the ac­tual off­sets shift by 32 bytes — the re­turn ad­dress lands at cre­den­tial body byte 200 (verified via De Bruijn pat­tern analy­sis from the re­mote ex­ploit).

Why NFS? The vul­ner­a­ble mod­ule kgss­api.ko im­ple­ments RPCSEC_GSS au­then­ti­ca­tion for the ker­nel’s RPC sub­sys­tem. NFS is the pri­mary (and typ­i­cally only) in-ker­nel RPC ser­vice that uses RPCSEC_GSS. The NFS server dae­mon (nfsd) lis­tens on port 2049/TCP and processes RPC pack­ets in ker­nel con­text — mak­ing this a re­mote ker­nel code ex­e­cu­tion vul­ner­a­bil­ity reach­able over the net­work.

Why Kerberos? The over­flow is deep in­side the GSS val­i­da­tion code path. svc_r­pc_gss_­val­i­date() is only called when:

The GSS pro­ce­dure is DATA (not INIT or DESTROY)

Without a valid GSS con­text, the server re­jects the packet at step 3 (returning AUTH_REJECTEDCRED) and the vul­ner­a­ble mem­cpy is never reached. Creating a valid GSS con­text re­quires a suc­cess­ful Kerberos hand­shake — the at­tacker must pos­sess a valid Kerberos ticket for the NFS ser­vice prin­ci­pal.

In a real-world at­tack, the tar­get would be an en­ter­prise NFS server with ex­ist­ing Kerberos in­fra­struc­ture (Active Directory, FreeIPA, etc.). Any user with a valid Kerberos ticket — even an un­priv­i­leged one — can trig­ger the vul­ner­a­bil­ity. The test lab in­cludes its own KDC be­cause there is no pre-ex­ist­ing Kerberos en­vi­ron­ment.

The XDR layer en­forces MAX_AUTH_BYTES = 400 on the cre­den­tial body, giv­ing an over­flow range of 97–400 bytes (1–304 bytes past the safe limit).

* Network ac­cess to the tar­get’s NFS port (2049/TCP) and KDC port (88/TCP)

# Download im­age

wget https://​down­load.freebsd.org/​re­leases/​VM-IM­AGES/​14.4-RE­LEASE/​amd64/​Lat­est/\

FreeBSD-14.4-RELEASE-amd64-BASIC-CLOUDINIT-ufs.qcow2.xz

xz -d FreeBSD-14.4-RELEASE-amd64-BASIC-CLOUDINIT-ufs.qcow2.xz

cp FreeBSD-14.4-RELEASE-amd64-BASIC-CLOUDINIT-ufs.qcow2 freebsd-vuln.qcow2

qemu-img re­size freebsd-vuln.qcow2 8G

# Cloud-init auto-con­fig­u­ra­tion

cat > user-data << ‘EOF’

#cloud-config

ch­passwd:

list: |

root:freebsd

ex­pire: False

ssh_p­wauth: True

bootcmd:

- rm -f /firstboot # pre­vent auto-patch­ing to -p1

- rm -f /var/db/freebsd-update/*

runcmd:

- echo ‘PermitRootLogin yes’ >> /etc/ssh/sshd_config

- ser­vice sshd restart

- kld­load kgss­api

- sysrc rpcbind_en­able=YES nf­s_serv­er_en­able=YES

- echo ‘/export -network 0.0.0.0/0’ > /etc/exports

- mkdir -p /export

- ser­vice rpcbind start && ser­vice nfsd start

EOF

cat > meta-data << ‘EOF’

in­stance-id: cve-test

lo­cal-host­name: freebsd-vuln

EOF

genisoim­age -output seed.iso -volid ci­data -joliet -rock user-data meta-data

# Boot VM — for­ward SSH (22), NFS (2049), and KDC (88) ports

qemu-sys­tem-x86_64 -enable-kvm -cpu host -m 2G -smp 2 \

-drive file=freebsd-vuln.qcow2,for­mat=qcow2,if=vir­tio \

-cdrom seed.iso \

-netdev user,id=net0,host­fwd=tcp::2222-:22,host­fwd=tcp::2049-:2049,host­fwd=tcp::8888-:88 \

-device vir­tio-net-pci,net­dev=net0 -nographic

The KDC port (88) is for­warded to host port 8888 di­rectly — no SSH tun­nel re­quired.

For VMware Workstation, ESXi, Fusion, VirtualBox, or bhyve. In this ex­am­ple the VM host­name is test.

Download the in­staller ISO (not the cloud-init im­age):

wget https://​down­load.freebsd.org/​re­leases/​amd64/​amd64/​ISO-IM­AGES/​14.4-RE­LEASE/\

FreeBSD-14.4-RELEASE-amd64-disc1.iso

IMPORTANT: FreeBSD spawns 8 NFS threads per CPU. The ex­ploit kills one thread per round and needs 15 rounds, so you need at least 2 CPUs (= 16 threads). With 1 CPU (8 threads) the ex­ploit fails around round 9.

Network: bridged or NAT (the at­tacker needs to reach ports 22, 88, 2049)

Attach the ISO and in­stall FreeBSD nor­mally

Border Gateway Protocol (BGP) is the postal ser­vice of the Internet. It’s re­spon­si­ble for look­ing at all of the avail­able paths that data could travel and pick­ing the best route. Unfortunately, it is­n’t se­cure, and there have been some ma­jor Internet dis­rup­tions as a re­sult. But for­tu­nately there is a way to make it se­cure.ISPs and other ma­jor Internet play­ers (Sprint and oth­ers) would need to im­ple­ment a cer­ti­fi­ca­tion sys­tem, called RPKI.

To bet­ter un­der­stand why BGP’s lack of se­cu­rity is so prob­lem­atic, let’s look at a sim­pli­fied model of how BGP is used to route Internet pack­ets. The Internet is not run by just one com­pany. It’s made up of thou­sands of au­tonomous sys­tems with nodes lo­cated all around the world, con­nected to each other in a mas­sive graph.In essence, the way BGP works is that each node must de­ter­mine how to route pack­ets us­ing only what it knows from the nodes it con­nects with di­rectly.For ex­am­ple, in the sim­ple net­work A–B–C–D–E, the node A only knows how to reach E based on in­for­ma­tion it re­ceived from B. The node B knows about the net­work from A and C. And so forth.A BGP hi­jack oc­curs when a ma­li­cious node de­ceives an­other node, ly­ing about what the routes are for its neigh­bors. Without any se­cu­rity pro­to­cols, this mis­in­for­ma­tion can prop­a­gate from node to node, un­til a large num­ber of nodes now know about, and at­tempt to use these in­cor­rect, nonex­is­tent, or ma­li­cious routes.Click “Hijack the re­quest” to vi­su­al­ize how pack­ets are re-routed:

In or­der to make BGP safe, we need some way of pre­vent­ing the spread of this mis­in­for­ma­tion. Since the Internet is so open and dis­trib­uted, we can’t pre­vent ma­li­cious nodes from at­tempt­ing to de­ceive other nodes in the first place. So in­stead we need to give nodes the abil­ity to val­i­date the in­for­ma­tion they re­ceive, so they can re­ject these un­de­sired routes on their own. Enter Resource Public Key Infrastructure (RPKI), a se­cu­rity frame­work method that as­so­ci­ates a route with an au­tonomous sys­tem. It gets a lit­tle tech­ni­cal, but the ba­sic idea is that RPKI uses cryp­tog­ra­phy to pro­vide nodes with a way of do­ing this val­i­da­tion.With RPKI en­abled, let’s see what hap­pens to pack­ets af­ter an at­tempted BGP hi­jack. Click “Attempt to hi­jack” to vi­su­al­ize how RPKI al­lows the net­work to pro­tect it­self by in­val­i­dat­ing the ma­li­cious routes:

Border Gateway Protocol (BGP) is the postal ser­vice of the Internet. When some­one drops a let­ter into a mail­box, the postal ser­vice processes that piece of mail and chooses a fast, ef­fi­cient route to de­liver that let­ter to its re­cip­i­ent. Similarly, when some­one sub­mits data across the Internet, BGP is re­spon­si­ble for look­ing at all of the avail­able paths that data could travel and pick­ing the best route, which usu­ally means hop­ping be­tween au­tonomous sys­tems. Learn more →By de­fault, BGP does not em­bed any se­cu­rity pro­to­cols. It is up to every au­tonomous sys­tem to im­ple­ment fil­ter­ing of “wrong routes”. Leaking routes can break parts of the Internet by mak­ing them un­reach­able. It is com­monly the re­sult of mis­con­fig­u­ra­tions. Although, it is not al­ways ac­ci­den­tal. A prac­tice called BGP hi­jack con­sists of redi­rect­ing traf­fic to an­other au­tonomous sys­tem to steal in­for­ma­tion (via phish­ing, or pas­sive lis­ten­ing for in­stance).BGP can be made safe if all au­tonomous sys­tems (AS) only an­nounce le­git­i­mate routes. A route is de­fined as le­git­i­mate when the owner of the re­source al­lows its an­nounce­ment. Filters need to be built in or­der to make sure only le­git­i­mate routes are ac­cepted. There are a few ap­proaches for BGP route val­i­da­tion which vary in de­grees of trusta­bil­ity and ef­fi­ciency. A ma­ture im­ple­men­ta­tion is RPKI. With 800k+ routes on the Internet, it is im­pos­si­ble to check them man­u­ally. Resource Public Key Infrastructure (RPKI) is a se­cu­rity frame­work method that as­so­ci­ates a route with an au­tonomous sys­tem. It uses cryp­tog­ra­phy in or­der to val­i­date the in­for­ma­tion be­fore be­ing passed onto the routers. You can read more about RPKI on the Cloudflare blog.On May 14th 2020, Job Snijders from NTT pre­sented a free RPKI 101 we­bi­nar.How does the test work?In or­der to test if your ISP is im­ple­ment­ing BGP safely, we an­nounce a le­git­i­mate route but we make sure the an­nounce­ment is in­valid. If you can load the web­site we host on that route, that means the in­valid route was ac­cepted by your ISP. A leaked or a hi­jacked route would likely be ac­cepted too.Can even more be done?Over the years, net­work op­er­a­tors and de­vel­op­ers started work­ing groups to de­sign and de­ploy stan­dards to over­come un­safe rout­ing pro­to­cols. Cloudflare re­cently joined a global ini­tia­tive called Mutually Agreed Norms for Routing Security (MANRS). It’s a com­mu­nity of se­cu­rity-minded or­ga­ni­za­tions com­mit­ted to mak­ing rout­ing in­fra­struc­ture more ro­bust and se­cure, and mem­bers agree to im­ple­ment fil­ter­ing mech­a­nisms. New voices are al­ways ap­pre­ci­ated.What can you do?Share this page For BGP to be safe, all of the ma­jor ISPs will need to em­brace RPKI. Sharing this page will in­crease aware­ness of the prob­lem which can ul­ti­mately pres­sure ISPs into im­ple­ment­ing RPKI for the good of them­selves and the gen­eral pub­lic. You can also reach out to your ser­vice provider or host­ing com­pany di­rectly and ask them to de­ploy RPKI and join MANRS. When the Internet is safe, every­body wins.

Michael Larabel is the prin­ci­pal au­thor of Phoronix.com and founded the site in 2004 with a fo­cus on en­rich­ing the Linux hard­ware ex­pe­ri­ence. Michael has writ­ten more than 20,000 ar­ti­cles cov­er­ing the state of Linux hard­ware sup­port, Linux per­for­mance, graph­ics dri­vers, and other top­ics. Michael is also the lead de­vel­oper of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org au­to­mated bench­mark­ing soft­ware. He can be fol­lowed via Twitter, LinkedIn, or con­tacted via MichaelLarabel.com.