Plugin-navn	Fremskridtsplanlægger
Type af sårbarhed	Cross-Site Scripting (XSS)
CVE-nummer	CVE-2026-28116
Hastighed	Lav
CVE-udgivelsesdato	2026-06-02
Kilde-URL	CVE-2026-28116

Hastere: Cross‑Site Scripting (XSS) i Progress Planner-plugin (≤ 1.9.0) — Hvad WordPress-webstedsejere skal gøre nu

Dato: 2. juni 2026
Forfatter: WP-Firewall Sikkerhedsteam

Oversigt:

En Cross‑Site Scripting (XSS) sårbarhed (CVE‑2026‑28116) er blevet offentliggjort i WordPress-pluginet “Progress Planner”, der påvirker versioner ≤ 1.9.0. Leverandøren har udgivet en patch i version 1.9.1. Sårbarheden kræver redaktørrettigheder for at blive udløst og kræver brugerinteraktion. Den fælles sårbarhedsvurderingssystem (CVSS) basis score er 5.9. Selvom den rapporterede prioritet er “Lav”, kan dette problem kædes sammen med mere alvorlige angreb på mange websteder, hvis det ikke adresseres. Dette indlæg forklarer risikoen, virkelige udnyttelsesscenarier, umiddelbare afbødningsforanstaltninger, detektions- og genopretningstrin, og hvordan WP‑Firewall kan beskytte dit websted — inklusive hvordan man kommer i gang med vores gratis plan.

---

Indholdsfortegnelse

• Hvad der blev rapporteret (hurtige fakta)
• Hvorfor XSS stadig betyder noget på WordPress-websteder
• Teknisk oversigt over Progress Planner XSS (hvad vi ved)
• Realistiske udnyttelsesscenarier og forretningspåvirkning
• Umiddelbare handlinger — trin-for-trin (hvad man skal gøre inden for den næste time, 24 timer, 7 dage)
• Hvis du ikke kan opdatere pluginet med det samme — kortsigtede afbødningsforanstaltninger
• Hvordan man opdager udnyttelse og indikatorer for kompromittering (IoCs)
• Genopretnings- og retsmedicinske tjekliste, hvis du mistænker et kompromis
• Hærdning og langsigtede forsvar (politik + teknisk)
• Hvordan WP‑Firewall beskytter dig (funktioner nyttige for dette problem)
• Beskyt dit site lige nu — start med WP‑Firewall gratis plan
• Resumé og endelige anbefalinger

---

Hvad der blev rapporteret (hurtige fakta)

• Berørt plugin: Progress Planner (WordPress-plugin)
• Sårbare versioner: ≤ 1.9.0
• Patchet version: 1.9.1
• Sårbarhedstype: Cross‑Site Scripting (XSS)
• CVE: CVE‑2026‑28116
• CVSS basis score: 5.9
• Nødvendig privilegium for udnyttelse: Redaktør
• Ekstra krav: Brugerinteraktion (f.eks. klik på et udformet link eller indsendelse af en formular)
• Rapporteret af: sikkerhedsforsker (kredit som offentliggjort af leverandøren)

Hvis du kører Progress Planner på dit site, skal du straks tjekke din plugin-version og anvende patchen (1.9.1 eller senere) som dit første og vigtigste skridt.

---

Hvorfor XSS stadig betyder noget på WordPress-websteder

XSS er en af de ældste web-sårbarheder, men den forbliver udbredt - især på platforme som WordPress, hvor mange plugins gengiver brugerleveret indhold. På WordPress kan XSS have en uforholdsmæssig stor indvirkning af flere grunde:

• WordPress-sider er økosystemer af kerne + temaer + plugins. Et enkelt plugin med en XSS-fejl kan påvirke hele sitet.
• Roller som Redaktør og Forfatter er almindelige på multi-bidragsydersider. Hvis en Redaktør-konto (eller kompromitteret Redaktør) kan injicere script i sider eller admin-skærme, kan angriberen målrette mod administratorer og site-besøgende.
• XSS er ofte en muliggører: når en angriber udfører JavaScript i en privilegeret brugers browser (for eksempel en administrator), kan de eskalere til kontoovertagelse (cookie-tyveri, CSRF til privilegerede endepunkter), installere bagdøre, injicere vedholdende ondsindet indhold eller pivotere til andre systemer.
• Automatiserede udnyttelsesværktøjer og masse-scanningsværktøjer søger efter XSS-vektorer i bredt anvendte plugins og temaer; et ikke-patcheret plugin kan blive et højvolumen indgangspunkt.

Selv når en sårbarhed har en “lav” prioriteringsvurdering, afhænger den praktiske risiko af konteksten - antal sider, der kører pluginet, hvordan Redaktør-roller er tildelt, og om administrative brugere har besøgt udnyttelige sider. Det er derfor, hurtig afbødning er nødvendig.

---

Teknisk oversigt over Progress Planner XSS (hvad vi ved)

Offentliggørelse indikerer, at Progress Planner-versioner op til og med 1.9.0 indeholder et XSS-problem. Leverandørens rådgivning opregner:

• Sårbarhedsklasse: Cross‑Site Scripting (XSS)
• Nødvendigt privilegium: Editor
• Brugerinteraktion nødvendig

Selvom leverandørens offentlige skrivelse ikke altid offentliggør fulde proof-of-concept udnyttelser af ansvarlige offentliggørelsesårsager, betyder tilstedeværelsen af en XSS-sårbarhed typisk, at mindst ét plugin-endepunkt eller felt accepterer input, der senere gengives uden korrekt output-encoding/escaping. Almindelige eksempler i plugins inkluderer:

• Tekstfelter, beskrivelser eller noter gemt som post-meta eller plugin-indstillinger, der senere vises i admin UI uden korrekt escaping.
• AJAX-endepunkter, der ekko input tilbage til browseren uden filtrering eller escaping.
• Shortcodes, widgets eller front-end komponenter, der gengiver gemt indhold, men ikke formår at rense eller escape HTML.

Fordi dette problem kræver Redaktør-rettigheder, skal en angriber enten have en Redaktør-konto eller narre en eksisterende Redaktør til at udføre en handling, der udløser payloaden (for eksempel at klikke på et link sendt via e-mail eller en udformet admin-URL).

Nøglepunkter fra den tekniske holdning:

• Dette er ikke en fjern uautentificeret overtagelse (ingen direkte RCE), men det er en vektor for kontoovertagelse og site-kompromittering, når det kombineres med social engineering eller misbrug af privilegier.
• Patchen er tilgængelig i 1.9.1. Opdatering er en komplet løsning fra leverandørens side og skal være det første afhjælpningsskridt.

---

Realistiske udnyttelsesscenarier og indvirkning

Nedenfor er plausible scenarier, der viser, hvorfor selv en XSS, der kræver Redaktør-rettigheder, er farlig:

1. Redigering-til-Admin pivot
   • En angriber får adgang til en redigeringskonto (credential reuse, phishing eller en kompromitteret underleverandør).
   • Angriberen opretter indhold, der indeholder ondsindet JavaScript, som gemmes af plugin'et.
   • Når en administrator åbner plugin-siden eller en hvilken som helst side, hvor det gemte indhold gengives, udføres scriptet i administratorens browser. Scriptet læser admin-session-cookien eller bruger adminens autentificerede session til at udføre handlinger (oprette en ny admin-bruger, ændre indstillinger, uploade et backdoor-plugin, ændre indhold).
   • Resultat: Fuld kontrol over siden.
2. Social engineering inden for organisationen
   • Angriberen laver et link, der udløser reflekteret XSS eller får redaktøren til at udføre en handling (indsende en tilpasset formular). Redaktøren bliver narret til at klikke. Scriptet udføres i redaktørens browser og kan manipulere indhold eller sende autentificeringstokens tilbage til angriberen.
3. Vedvarende omdømme- og SEO-skade
   • Gemt XSS payload ændrer front-end indhold for besøgende på siden (indsætter spam-links, omdirigerer til ondsindede domæner eller viser falske annoncer). Dette skader SEO, kan få siden flaget af søgemaskiner og koster tid og penge at udbedre.
4. Leverandørkædeudnyttelse
   • Hvis plugin'et bruges af mange sider, kan en angriber, der kan udnytte redigeringskonti på tværs af flere sider, køre massekampagner (f.eks. annoncebedrageri, phishing-distribution), ved at bruge plugin'et som den indledende vektor.

Selv når udnyttelse kræver brugerinteraktion, bruger mange virkelige kampagner med succes social engineering til at udløse disse interaktioner. Behandl dette som en høj-urgens patch-begivenhed.

---

Øjeblikkelige handlinger — trin-for-trin

Hvis du driver en WordPress-side ved hjælp af Progress Planner, skal du følge denne prioriterede tjekliste.

Handlinger, der skal tages i den næste time

1. Tjek din plugin-version
   • Dashboard → Plugins → find Progress Planner. Hvis versionen er ≤ 1.9.0, skal du handle straks.
2. Hvis muligt, opdater til 1.9.1
   • Opdater plugin'et til version 1.9.1 eller den nyeste udgivelse fra forfatteren. Dette er den definitive løsning fra leverandøren.
3. Begræns redaktøraktivitet midlertidigt
   • Hvis du ikke kan opdatere med det samme, skal du midlertidigt begrænse redaktørens muligheder:
     • Deaktiver redaktørrollen fra at oprette eller redigere indhold, som plugin'et behandler.
     • Alternativt, midlertidigt nedgradere Editor-brugere indtil der er en patch.
4. Aktivér WP‑Firewall beskyttelsesregler (hvis du bruger en WAF)
   • Implementer generiske XSS beskyttelsesregler eller den virtuelle patch, vi beskriver nedenfor.
   • Hvis du er på WP‑Firewall platformen, skal du sikre dig, at din side har den administrerede firewall og WAF aktiveret, og at trusselregler er aktive.

Handlinger der skal tages inden for 24 timer

1. Scann siden for mistænkelige scripts eller injiceret indhold
   • Søge post_indhold og post_meta for ., en fejl=, onload=, javascript:, eval(, eller mistænkelige base64 blobs.
   • Søg i uploads-mappen efter nyoprettede PHP-filer eller ukendte filer.
2. Gennemgå Editor-konti og nylig aktivitet
   • Gennemgå brugerlisten — se efter ukendte/editor-konti.
   • Gennemgå Nylig Aktivitet og revisionslogs (hvis tilgængelige) for at se, om redaktører har tilføjet indhold, der kunne udnytte fejlen.
3. Tving nulstilling af adgangskoder for privilegerede brugere, hvis kompromittering mistænkes
   • Hvis du identificerer usædvanlig aktivitet, tving nulstilling af adgangskoder for redaktører og administratorer.

Handlinger der skal tages inden for 7 dage

1. Fuld malware-scanning
   • Udfør en komplet site-scanning (filer + database). Hvis du bruger WP‑Firewall, kør scanneren, der er inkluderet i tjenesten.
2. Fuld site backup
   • Opret en ren, offline backup før nogen afhjælpningstiltag, der vil ændre data til retsmedicinske formål.
3. Patch andre plugins og kernen
   • Mens du patcher Progress Planner, skal du sikre dig, at WordPress-kernen, temaer og andre plugins også er opdaterede.

---

Hvis du ikke kan opdatere med det samme — midlertidige afbødninger (virtuel patching)

Hvis opdateringer er forsinkede (kompatibilitetstest, stagingkrav eller hostingbegrænsninger), brug disse afbødninger:

1. Bloker kendte udnyttelsespayloads via WAF-regler
   • Tilføj regler for at blokere anmodninger, der indeholder mistænkelige script-tags eller JavaScript-begivenhedsattributter i pluginens slutpunkter.
   • Eksempel (pseudokode/modsec stil):
     • Bloker anmodninger, hvor REQUEST_URI matcher plugin-administrator eller AJAX slutpunkter, og ARGS|ARGS_NAMES indeholder <script eller en fejl= eller javascript:.
   • Justering: undgå alt for brede regler, der bryder gyldigt indhold; begræns regler til plugin slutpunkter og administrator kontekster.
2. Begræns adgangen til plugin-adminsider.
   • Brug .htaccess, webserverregler eller et adgangskontrolplugin for at begrænse adgangen til pluginens administrationssider efter IP (hvis dit administrationsteam bruger faste IP'er) eller kun VPN.
3. Deaktiver midlertidigt plugin'et
   • Hvis pluginen ikke er essentiel for den umiddelbare drift af siden, deaktiver den, indtil du sikkert kan opdatere.
4. Hærd redaktørinteraktioner
   • Forhindre redaktører i at uploade visse filtyper.
   • Begræns redaktørens evne til at tilføje ikke-betroet HTML eller scripts ved at bruge indholdssanitizers eller ved at forbyde indlejring af rå HTML i blokredaktøren.
5. Anvend en Content Security Policy (CSP)
   • Implementer en restriktiv CSP, der blokerer inline scripts og kun tillader scripts fra betroede kilder. Dette reducerer virkningen af injicerede scripts, selvom CSP skal testes for at undgå at bryde legitime administrationsscripts.
6. Overvåg og alarmer om mistænkelige ændringer
   • Tænd for filintegritetsovervågning og alarmering for ændringer i kernepluginfiler og uploads.

Selvom disse er nødforanstaltninger, køber de tid til en fuld opdatering og retsmedicinsk gennemgang.

---

Hvordan man opdager udnyttelse — indikatorer for kompromittering (IoCs)

Søg efter følgende tegn i både filer og database:

Databasekontroller

• post_indhold eller postmeta der indeholder ., en fejl=, onload=, javascript:, eller mistænkelige kodede strenge (base64, escape-sekvenser).
• Uventede shortcodes eller pluginmuligheder, der indeholder HTML/JS.
• Nye eller ændrede indlæg/sider, du ikke har godkendt.

Fil systemkontroller

• Nye PHP-filer i /wp-content/uploads/ eller andre skrivbare kataloger.
• Ændrede plugin- eller tema-filer (sammenlign med leverandørpakken).
• Mistænkelige cron-jobs eller planlagte opgaver tilføjet via wp_cron.

Adfærdsmæssige og trafikindikatorer

• Besøgende ser omdirigeringer til spam/mangfoldige annonce-domæner eller popups.
• Søgemaskineadvarsler eller pludselige fald i organisk trafik.
• Logposter, der viser gentagne POST-anmodninger til plugin-endepunkter med script-tags eller usædvanlige nyttelaster.

Bruger- og kontoindikatorer

• Nye administrator-konti eller ændringer til brugerroller, du ikke har godkendt.
• Mislykkede login-forsøg efterfulgt af succesfulde sessioner fra usædvanlige IP-adresser.

Hvis du ser nogen af disse, skal du behandle siden som potentielt kompromitteret og følge genopretningstrinene nedenfor.

---

Genopretnings- og retsmedicinsk tjekliste (hvis du mistænker kompromittering)

1. Isoler stedet
   • Sæt siden i vedligeholdelsestilstand eller tag den midlertidigt offline for at forhindre yderligere skade og dataudtræk.
2. Bevar beviser
   • Tag et snapshot af databasen og filsystemet, før du foretager ændringer.
   • Indsaml serverlogs (webserver, PHP, WAF-logs) og eksportér dem til analyse.
3. Rens og fjern ondsindet indhold
   • Fjern injicerede scripts fundet i indlæg, plugin-indstillinger og tema-filer.
   • Gendan ændrede plugin-filer til leverandørkopier (slet og geninstaller plugin, hvis nødvendigt).
   • Fjern ukendte eller mistænkelige PHP-filer i uploads.
4. Roter legitimationsoplysninger
   • Tving adgangskode-nulstillinger for alle brugere med forhøjede rettigheder — Admin, Redaktør, Forfatter.
   • Tilbagekald eventuelle aktive sessioner (WordPress understøtter sessioninvalidisering gennem brugermeta eller single sign-on-løsninger).
5. Geninstaller ren plugin-pakke
   • Slet det sårbare plugin og installer en frisk kopi af version 1.9.1 (eller senere) fra den officielle kilde. Gendan ikke fra en sikkerhedskopi, der er ældre end den rene tilstand uden inspektion.
6. Gen-scann og overvåg
   • Kør en fuld malware-scanning efter oprydning og fortsæt med at overvåge logfiler for gentagelse.
7. Overvej professionel hjælp
   • Hvis angrebet virker komplekst, eller hvis du mangler interne ressourcer, så engager en incident response-udbyder med erfaring i WordPress.
8. Dokumenter hændelsen
   • Hold en tidslinje over, hvad der blev fundet, afhjælpningsskridt og hvorfor beslutninger blev truffet. Dette er uvurderligt til efterforskning og forsikringsformål.

---

Hærdning og langsigtede forsvar

For at reducere risikoen fra lignende sårbarheder i fremtiden, vedtag denne lagdelte tilgang:

1. Princippet om mindste privilegium
   • Undgå at give redaktør- eller forfatterlegitimation til brugere, der ikke har brug for dem.
   • Brug granulære kapabilitets-plugins eller brugerdefinerede roller, hvor det er muligt.
2. Håndhæve Multi-Factor Authentication (MFA)
   • Kræv MFA for alle brugere med forhøjede privilegier.
3. Kontinuerlig patchingpolitik
   • Oprethold en ugentlig eller hver anden uge tidsplan for patching af plugins og temaer i staging før produktion.
4. Staging og test
   • Test alle plugin-opdateringer i et staging-miljø før produktion, hvor det er praktisk.
5. Regelmæssig sikkerhedsscanning
   • Planlæg automatiserede fil- og databasescanninger for ondsindet indhold og anomalier.
6. Web Application Firewall (WAF) med virtuel patching
   • En administreret WAF kan blokere udnyttelsesforsøg i realtid, selv før leverandørpatches er installeret.
7. Indholdssikkerhedspolitik (CSP) og sikkerhedshoveder
   • Implementer en CSP for at begrænse inline-scripts, håndhæve HTTPS og indstille passende X-Frame-Options, X-Content-Type-Options og Referrer-Policy headers.
8. Filintegritetsmonitorering og sikkerhedskopier
   • Hold uforanderlige, off-site backups og verificer regelmæssigt deres integritet.
9. Audit-logføring og overvågning
   • Hold revisionslogfiler for brugeraktivitet og filændringer; integrer med alarmer for mistænkelige hændelser.

---

Hvordan WP-Firewall beskytter dig (de funktioner, der betyder noget for dette problem)

Hos WP-Firewall fokuserer vi på praktisk, lagdelt beskyttelse, der specifikt adresserer den slags risiko, der udgøres af Progress Planner XSS:

• Administreret firewall og WAF
  • Vores administrerede firewall inspicerer indkommende anmodninger, blokerer kendte ondsindede payloads (scriptinjektionsmønstre) og isolerer mistænkelige anmodninger rettet mod plugin-administration og AJAX-endepunkter.
  • Virtuel patching: når vi opdager en ny sårbarhed, kan vores team implementere målrettede WAF-regler for at blokere udnyttelsesforsøg på tværs af dine websteder, mens du planlægger og implementerer leverandøropdateringer.
• Malware-scanner og filintegritetskontroller
  • Planlagte scanninger søger efter ondsindede filer og injicerede scripts. Filintegritetsovervågning advarer dig om ændringer i plugin-filer eller uventede uploads.
• OWASP Top 10 afbødning
  • Forudbyggede signaturer og regelsæt afbøder almindelige injektionsvektorer som XSS, SQLi og andre.
• Angrebsdetektion og logning
  • Detaljerede logs viser forsøgte udnyttelsesmønstre og kilde-IP'er. Disse logs hjælper dig med at identificere mistænkelige brugerkonti og angriberes infrastruktur.
• Vejledning til støtte efter hændelsen
  • Vores team leverer playbooks og anbefalede trin, hvis vi opdager et aktivt udnyttelsesforsøg.

Funktionskortlægning til Progress Planner-issue

• Hvis du ikke kan opdatere med det samme, blokerer WP‑Firewall's WAF-signaturer og virtuelle patching for payloads, der ville udnytte uescaperede felter og plugin-endepunkter. Dette reducerer risikoen drastisk.
• Vores malware-scanner vil opdage og markere injicerede scripts i databasen og uploads-mappen.
• Den administrerede firewall kan begrænse adgangen til admin-endepunkter efter IP eller geografi, mens du udbedrer.

---

Beskyt dit site lige nu — start med WP‑Firewall gratis plan

Hvis du læser dette og ønsker at få et øjeblikkeligt, praktisk lag af beskyttelse foran dine WordPress-installationer, tilmeld dig WP‑Firewall Basic (Gratis) planen. Den gratis plan inkluderer essentielle beskyttelser, der er direkte relevante for denne sårbarhed:

• Administreret firewall med WAF (blokerer almindelige XSS-mønstre)
• Ubegribelig båndbredde til sikkerhedstrafik
• Malware-scanner, der inspicerer filer og databasen for injicerede scripts
• Forudbygget afbødning for OWASP Top 10-risici (inklusive XSS)

Opgraderingsmuligheder er tilgængelige, hvis du ønsker automatisk malwarefjernelse, IP-blacklist/whitelist-kontroller, virtuel patching og administrerede tjenester. Start med den gratis plan i dag og reducer din eksponering, mens du planlægger patching og oprydning: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Praktiske forespørgsler og eksempler — hvordan man tjekker dit site

Nedenfor er konkrete forespørgsler og kommandoer til at hjælpe dig med hurtigt at finde mulig injiceret indhold. Kør disse i din database og shell som passende, eller bed din host/udvikler om at køre dem:

WordPress-database søgeeksempler (brug phpMyAdmin eller WP‑CLI):

• Søg indlæg for scripts:

  VÆLG ID, post_title FRA wp_posts HVOR post_content LIKE '%

• Søg muligheder og postmeta:

  VÆLG option_name FRA wp_options HVOR option_value LIKE '%
  
  VÆLG meta_id, meta_key FRA wp_postmeta HVOR meta_value LIGNER '%<script%';

Linux grep-eksempler (fra WordPress-roden):

• Find script-tags i filer (uploads er ofte målrettet):

  grep -RIn "<script" wp-content/uploads || true

• Find nyligt ændrede filer:

  find . -type f -mtime -7 -print

Revisionslogfiler og WAF-logfiler
Gennemgå WP‑Firewall eller hosting WAF-logfiler for anmodninger, der indeholder <script, en fejl=, eval(, base64_decode, eller anmodninger til plugin-endepunkter med mistænkelige nyttelaster.

---

Anbefalede detektionsregler (eksempler til erfarne administratorer)

Nedenfor er eksempler på detektionsmønstre (konceptuelle — tilpas til dit miljø og test omhyggeligt):

1. Bloker POST-anmodninger til plugin-administrator/AJAX-endepunkter, der indeholder <script:
   • Betingelse: REQUEST_METHOD == POST OG REQUEST_URI indeholder /wp-admin/admin.php?page=progress-planner ELLER indeholder progress-planner OG ARGS eller ARGS_NAMES indeholder <script eller en fejl=
2. Flag anmodninger, der indeholder dokument.cookie, XMLHttpRequest, eller fetch( i parametre til administrator-endepunkter.
3. Giv alarm ved nye administratorbrugere oprettet fra IP-adresser, der ikke er på din kendte administrator-IP-liste.

Note: Undgå alt for brede regler, der bryder legitime redaktørers brug. Afgræns regler til plugin-endepunkter og administrator-kontekst, hvor det er muligt.

---

Resumé og endelige anbefalinger

• Øjeblikkelig prioritet: Hvis du kører Progress Planner, opdater til version 1.9.1 nu. Dette er leverandørens løsning og lukker den rapporterede XSS-sårbarhed (CVE‑2026‑28116).
• Hvis du ikke kan opdatere med det samme, brug en administreret WAF (virtuel patching), begræns redaktøraktivitet og scan for injicerede scripts.
• Overvåg for indikatorer på kompromittering nævnt ovenfor, bevar logfiler og sikkerhedskopier, og følg genopretningschecklisten, hvis du finder beviser for udnyttelse.
• Vedtag en lagdelt sikkerhedsstrategi: mindst privilegium, MFA for privilegerede konti, automatiseret scanning, administrerede WAF-beskyttelser og konsekvent patching-cyklus.

Hos WP‑Firewall står vi klar til at hjælpe dig med at reducere eksponering og reagere hurtigt på hændelser som denne. Vores gratis plan giver øjeblikkelig WAF-dækning og scanning for at fange de mest almindelige udnyttelsesforsøg, mens du udfører leverandøropdateringer og retsmedicinske kontroller. Læs mere og tilmeld dig her: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Hold jer sikre,
WP-Firewall Sikkerhedsteam

---

Hvis du ønsker det, kan vi tilbyde:

• Et klar-til-at-anvende WAF-regelsæt tilpasset dette plugin (kræver administratoradgang til din WP‑Firewall-konsol).
• En hurtig tjekliste tilpasset dit sites brugerroller og publiceringsarbejdsgang.
• Assistance med at køre database- og filsøger efter injiceret indhold.