Bricksforge CVE-2026-85097 blir utnyttet: oppdater Pro Forms nå

#Er Bricksforge-nettstedet mitt sårbart for CVE-2026-85097

Alle Bricksforge-installasjoner på 3.1.8.9 eller lavere er det. Det er spennet i NVD-oppføringen og i Wordfence-databasen. Angriperen trenger verken innlogging eller et klikk fra noen hos deg.

Et opplastingsfelt i skjemaet er ikke en forutsetning. I leverandørens endringslogg står det rett ut ved 4.0.1 at problemet gjelder alle nettsteder med aktiv Pro Forms, også der skjemaene ikke har opplastingsfelt. “Vi har jo bare et kontaktskjema” holder altså ikke som grunn til å vente.

Alvorlighetsgraden avhenger av kilden. Patchstack gir 10.0 og merker hullet som kjent utnyttet (KEV). Wordfence og NVD gir 9.8 med CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. For deg som eier nettstedet er forskjellen uten betydning: angrep over nettet, ingen rettigheter, full konsekvens.

Bricksforge er en kommersiell utvidelse. Utvidelses-API-et på WordPress.org svarer “Plugin not found”. Det betyr noe to steder nedenfor: oppdateringer kommer via lisensen hos leverandøren, ikke fra katalogen, og wp plugin verify-checksums har ingenting å sammenligne med.

#Hvordan fungerer opplastingshullet i Bricksforge Pro Forms

CVE-beskrivelsen og analysen fra Patchstack beskriver tre steg:

1. Angriperen henter en gyldig nonce fra AJAX-handlingen bricksforge_regenerate_nonce, som svarer uten innlogging.
2. Hen laster opp en fil som både er en gyldig GIF og gyldig PHP, en såkalt polyglott. MIME-sjekken ved første opplasting slipper den gjennom, fordi filen faktisk ser ut som et bilde. Den havner i en midlertidig mappe.
3. Hen sender et skjema med en manipulert temporaryFileUploads-parameter. Stien på serveren peker på den godkjente GIF-en, mens feltet url slutter på .php. Utvidelsen stoler på metadataene klienten sendte og skriver innholdet til en PHP-sti.

Patchstack peker på to inngangspunkter: POST /wp-json/bricksforge/v1/form_submit og /wp-admin/admin-ajax.php med handlingen bricksforge_form_submit. Koden det gjelder ligger i includes/elements/pro-forms/actions/init.php og base.php. Ifølge CVE-oppføringen ble leverandøren varslet 3. september 2026, og hullet ble offentliggjort 7. oktober. Finneren er oppgitt som d.v4n_s3c.

#Hvordan sjekker jeg Bricksforge-versjonen i wp-admin og med WP-CLI

I kontrollpanelet: Utvidelser, Installerte utvidelser, raden for Bricksforge, versjonsnummeret under beskrivelsen. Har lisensen gått ut, kan det hende kontrollpanelet ikke viser en oppdatering som faktisk finnes. Ingen varsling betyr ikke at du er oppdatert.

Over SSH, for ett nettsted:

wp plugin list --name=bricksforge --fields=name,status,version,update_version

Drifter du mange kundenettsteder på samme server, gir en løkke deg oversikten på sekunder:

for d in /var/www/*/public_html; do
  printf '%s ' "$d"
  wp --path="$d" plugin get bricksforge --field=version 2>/dev/null || echo "ikke installert"
done

Tilpass stien til oppsettet ditt. Alt på 3.1.8.9 eller lavere havner på listen for oppdatering og kontroll.

#Skal jeg oppdatere Bricksforge til 3.1.8.10 eller 4.0.1

Kildene er ikke enige, og det bør du vite før du trykker Oppdater.

• Patchstack og Wordfence oppgir begge 3.1.8.10 som rettet versjon.
• Leverandørens endringslogg har per 10. oktober 2026 ingen oppføring for 3.1.8.10. Den viser 3.1.8.9 (28. august), 4.0.0 (17. september) og 4.0.1 (8. oktober), den siste med tittelen “Security fix for the Pro Forms file upload”.

Tommelfingerregelen: etter oppdateringen skal versjonen være 3.1.8.10, eller 4.0.1 og høyere. Står du på 4.0.0, gå til 4.0.1. Ingen av kildene sier rett ut om 4.0.0 er sårbar, men leverandøren leverte opplastingsrettelsen i 4.0.1, så det er ingen grunn til å bli stående.

wp plugin update bricksforge
wp plugin get bricksforge --field=version

Ser ikke WP-CLI noen oppdatering, last ned zip-filen fra kundekontoen hos leverandøren og installer fra fil: wp plugin install /tmp/bricksforge.zip --force. Hoppet til 4.x er en ny hovedversjon. På et nettsted med kompliserte skjemaer kjører du den på staging først, i dag og ikke neste uke.

Kan du ikke oppdatere ennå? Deaktiver utvidelsen (wp plugin deactivate bricksforge) eller blokker begge endepunktene i WAF-en. Patchstack har rullet ut en RapidMitigate-regel for denne CVE-en til kundene sine. Patchstack selv kaller det en midlertidig løsning, ikke en erstatning for oppdateringen.

#Hva må jeg sjekke hvis nettstedet kjørte Bricksforge 3.1.8.9 eller eldre

Oppdateringen lukker døren. Den kaster ikke ut den som allerede har kommet inn. 7. oktober er første observasjon i Patchstacks telemetri, ikke bevis på at ingen prøvde tidligere. Gå derfor gjennom et bredere tidsvindu, for eksempel fra 3. september, da leverandøren ble varslet.

#Nye administratorkontoer

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Sammenlign med folkene du kjenner. En konto opprettet de siste ukene, med en adresse på et ukjent domene eller et brukernavn som wp-support, er grunn nok til full gjennomgang. Sjekk også applikasjonspassord: wp user application-password list <ID> for hver administrator.

#PHP-filer i opplastingsmappen

Kjørbar PHP hører ikke hjemme i wp-content/uploads. Patchstack fant filer kalt login_admin_*.php i /wp-content/uploads/bricksforge/tmp/ og /wp-content/uploads/2026/10/.

find wp-content/uploads -type f \( -iname '*.php*' -o -iname '*.phtml' -o -iname '*.phar' \) -ls
find wp-content/uploads -type f -name 'login_admin_*' -ls
ls -la wp-content/uploads/bricksforge/tmp/

Mønsteret *.php* med -iname fanger også .php5 og .PHP. Patchstack rapporterer varianter av filendelser, store og små bokstaver og koding i nyttelastene, så ikke søk bare etter nøyaktig .php. Se også etter fremmede .htaccess-filer i uploads, siden de kan få andre filendelser til å kjøres som PHP.

#Endrede filer i kjerne, temaer og utvidelser

wp core verify-checksums
find wp-content -type f -name '*.php' -newermt '2026-09-03' ! -path '*/cache/*' -ls

Kjernen sjekker du mot sjekksummer. Bricksforge og Bricks ligger ikke på WordPress.org, så last ned rene kopier fra leverandøren og sammenlign med diff -r. Se spesielt i wp-content/mu-plugins, der kode alltid lastes og aldri vises i utvidelseslisten, og i wp-config.php.

#Planlagte oppgaver

wp cron event list --fields=hook,next_run_relative,recurrence
crontab -l

Ukjente hooks i WP-Cron, eller en crontab-linje som henter noe fra en ekstern adresse, er den klassiske veien tilbake etter at et webshell er slettet.

#Serverlogger

Søk etter endepunktene fra rapporten til Patchstack:

grep -E 'bricksforge/v1/form_submit|bricksforge_regenerate_nonce|bricksforge_form_submit' access.log*
zgrep -E 'bricksforge/v1/form_submit' access.log*.gz
grep -E '^(177\.75\.57\.20|23\.97\.62\.146|84\.247\.60\.125|38\.154\.185\.97|150\.109\.16\.166|153\.75\.90\.146) ' access.log*
grep -E 'GET /wp-content/uploads/.*\.php' access.log*

De seks adressene er de mest aktive av de 63 unike IP-ene Patchstack telte i kampanjen. En begrensning: en vanlig tilgangslogg lagrer bare URL-en, og navnet på AJAX-handlingen sendes ofte i POST-innholdet. Et kall til admin-ajax.php trenger altså ikke inneholde “bricksforge” i loggen. Korreler da på IP og tidspunkt. Det sterkeste tegnet er en vellykket GET mot en .php-fil under uploads med status 200.

#Når bør jeg gjenopprette WordPress fra sikkerhetskopi

Én PHP-fil i uploads som du ikke kan forklare, eller én ukjent administratorkonto, og nettstedet regnes som kompromittert. Kode som kjørte på serveren hadde tilgang til databasen, filene og wp-config.php. Å slette én fil for hånd sier deg ikke om det var den eneste.

Rekkefølgen som fungerer:

1. Ta et øyeblikksbilde av dagens tilstand, filer og database, som bevis før du sletter noe.
2. Gjenopprett filer fra en sikkerhetskopi tatt før første mistenkelige loggoppføring. Går ikke loggene så langt tilbake, velg en kopi fra før 3. september og legg inn senere innhold for hånd.
3. Oppdater Bricksforge til 3.1.8.10 eller 4.0.1 før nettstedet går på nett igjen. Kopien du la tilbake har den gamle, sårbare versjonen.
4. Bytt passord for database, SFTP og alle administratorer, lag nye nøkler i wp-config.php (wp config shuffle-salts) og trekk tilbake applikasjonspassord.

Pro Forms-skjemaer samler som regel inn navn, e-postadresser og meldinger. Hadde angriperen tilgang til databasen, kan det være et brudd på personopplysningssikkerheten etter GDPR artikkel 33, som skal meldes til Datatilsynet innen 72 timer etter at du ble kjent med det, med mindre det er lite sannsynlig at bruddet medfører risiko for de registrerte. Dokumenter funnene, også om du ender med at melding ikke trengs.

Finner kontrollen ingenting, er gjenoppretting ikke nødvendig. Noter hva du sjekket og når.

#Fjerde Bricksforge-sårbarhet i 2026

Oversikten hos Wordfence viser tidligere oppføringer fra samme år: CVE-2026-14956 (til og med 3.1.8.6, rettighetseskalering uten innlogging via Pro Forms, 9.8), CVE-2026-18030 (til og med 3.1.8.7, rettighetseskalering uten innlogging via tilbakestilling av passord, 9.8) og CVE-2026-84814 (til og med 3.1.8.8, rettighetseskalering fra abonnent, 6.3). Tre av fire handler om skjemaer eller innloggingslogikk.

Det er ingen grunn til å rive ut utvidelsen i panikk. Det er en grunn til at noen sjekker Bricksforge på kundenettsteder hver uke, ikke én gang i kvartalet.

#Hvordan en vedlikeholdsavtale fanger opp slike hull

Et hull som utnyttes uten innlogging gir deg dager, noen ganger timer. En avtale om vedlikehold av WordPress-nettsider bør dekke de tre tingene som avgjør utfallet her:

• en oversikt over utvidelser og versjoner per nettsted, også kommersielle, fordi varslene fra katalogen ikke når utvidelser utenfor WordPress.org,
• sårbarhetsvarsler (Patchstack, Wordfence, NVD) som sammenlignes med den oversikten, slik at Bricksforge-varselet havner hos noen som vet at du bruker det,
• tilgangslogger som tas vare på lenger enn noen dager, for uten dem har spørsmålet “kom noen inn før oppdateringen” ikke noe svar.

Er du usikker på om nettstedet kom rent gjennom denne uken, dekker en sikkerhetsrevisjon av WordPress nøyaktig stegene på denne listen: uploads, kontoer, cron, sjekksummer og logger.

Sist oppdatert 10. oktober 2026. Kilder: artikkel og databaseoppføring fra Patchstack (7. og 8. oktober 2026), oppføring i Wordfence Intelligence, NVD-oppføring for CVE-2026-85097, endringsloggen til Bricksforge, GDPR artikkel 33.