| Plugin-navn | WordPress Private Google Kalender Plugin |
|---|---|
| Type af sårbarhed | Adgangskontrol sårbarhed |
| CVE-nummer | CVE-2025-12526 |
| Hastighed | Lav |
| CVE-udgivelsesdato | 2026-02-02 |
| Kilde-URL | CVE-2025-12526 |
Brudt Adgangskontrol i ‘Private Google Calendars’ WordPress Plugin (CVE-2025-12526) — Hvad webstedsejere skal gøre nu
Dato: 2026-02-02
Forfatter: WP-Firewall Sikkerhedsteam
Oversigt
- Sårbarhed: Brudt Adgangskontrol — Manglende autorisation, der tillader autentificerede (Subscriber+) konti at nulstille plugin-indstillinger.
- Berørt plugin: Private Google Calendars — versioner <= 20250811
- Rettet i: 20251128
- CVE: CVE-2025-12526
- Rapporteret af: Athiwat Tiprasaharn (Jitlada)
- Alvorlighed: Lav (CVSS 4.3) — integritetsindvirkning (nulstilling af indstillinger), kræver en autentificeret konto
- Anbefalet øjeblikkelig handling: Opdater til 20251128 når det er muligt. Hvis du ikke kan opdatere med det samme, anvend afbødninger og brug virtuel patching via din WAF.
Indledning
Jeg skriver dette som en del af WP-Firewall sårbarhedsrespons teamet for at give dig en praktisk, ligefrem oversigt over den nyligt offentliggjorte sårbarhed, der påvirker Private Google Calendars plugin (CVE-2025-12526). Forskningen indikerer en brudt adgangskontroltilstand, der tillader en autentificeret bruger med Subscriber-niveau privilegier (eller højere) at udløse en nulstillingsoperation, der burde have krævet en stærkere autorisationskontrol.
Dette indlæg forklarer den tekniske risiko, hvordan en angriber muligvis kan udnytte det i praksis, hvordan man opdager tegn på udnyttelse, øjeblikkelige afbødninger, du kan implementere i dag (inklusive WAF/virtuel patching mønstre), og langsigtet hærdningsrådgivning til både webstedsejere og plugin-udviklere. Jeg vil også forklare, hvordan WP-Firewall kan hjælpe med at beskytte websteder, mens du planlægger en opdatering.
Note: Vi vil undgå at offentliggøre udnyttelseskode eller trin-for-trin instruktioner, der væsentligt ville hjælpe angribere. Denne vejledning er rettet mod forsvarere og webstedadministratorer.
Indholdsfortegnelse
- Hvad er præcist “brudt adgangskontrol” i denne sammenhæng?
- Hvorfor denne sårbarhed er vigtig (virkelige konsekvenser)
- Sårbarhedsmekanik — hvordan problemet introduceres
- Udnyttelighed og trusselmodel
- Indikatorer for kompromis og hvordan man opdager misbrug
- Øjeblikkelige afbødningsskridt for webstedsejere (patching og midlertidige beskyttelser)
- Virtuel patching med en Web Application Firewall (anbefalede WAF-regelmønstre)
- Kode-niveau fix vejledning for plugin-udviklere
- Driftsanbefalinger og hårdningscheckliste
- Hvordan WP-Firewall hjælper (administreret firewall, virtuelle patches, scanning)
- Information om gratis plan: Beskyt din side i dag
- Afsluttende anbefalinger og tjekliste
Hvad er præcist “brudt adgangskontrol” i denne sammenhæng?
Brud på adgangskontrol betyder generelt, at applikationen udfører en handling uden at kontrollere, om den nuværende bruger er autoriseret til at udføre den. I problemet med Private Google Calendars-pluginet krævede en funktion, der nulstiller pluginindstillinger (en højpåvirkningsadministrativ operation set fra applikationens perspektiv), ikke en passende kapabilitetskontrol eller nonce-verifikation. Som et resultat kunne enhver autentificeret bruger - specifikt konti med abonnentniveau privilegier eller derover - kalde den funktion og udløse en nulstilling af pluginens indstillinger.
Nøglepunkter:
- Handlingen kræver en autentificeret bruger (så anonyme brugere ikke kan udnytte dette, medmindre der er en yderligere fejlkonstruktion).
- Problemet opstår, fordi pluginet ikke verificerer, at den autentificerede konto har de rette administrative tilladelser.
- Der mangler også en nonce-kontrol eller er utilstrækkelig, hvilket øger risikoen for CSRF-lignende misbrug, når en angriber kan få en indlogget bruger til at besøge en ondsindet side.
Hvorfor denne sårbarhed er vigtig (virkelige konsekvenser)
Ved første øjekast kan en “nulstilling af indstillinger” lyde harmløs. Men overvej virkelige scenarier:
- Nulstilling af pluginindstillinger kan afbryde eksterne legitimationsoplysninger (Google API-nøgler) eller tilbageføre synligheds- og adgangsindstillinger, der var omhyggeligt konfigureret. Det kan resultere i tjenesteafbrydelse eller utilsigtet offentlig eksponering af kalenderposter.
- Angribere kunne gentagne gange udløse nulstillinger for at forårsage en denial-of-service på kalenderfunktionen eller skabe administrativ forvirring og unødvendigt remedieringsarbejde.
- Hvis nulstillingshandlingen berører vedvarende konfiguration, der bruges af andre plugins eller autoriserede integrationer, kunne angribere tvinge legitimationsrotation eller introducere huller, der gør opfølgende angreb lettere.
- Hvis en side tillader offentlig registrering eller har mange abonnentniveau brugere (for eksempel fællesskaber, medlemskabssteder, LMS-installationer), er angriberbasen større.
- Fordi problemet kræver autentificering, er det ikke et totalt kompromis fra anonyme brugere, men barrieren er lav på mange sider, der muliggør brugerregistrering.
Dette er grunden til, at vi vurderer det som “Lavt” på CVSS-niveauet: udnyttelse kræver autentificeret adgang (en lille barriere), og den primære påvirkning er integritet (indstillinger), ikke direkte dataeksfiltrering eller fuld overtagelse af siden. Men i mange operationelle sammenhænge kan det at tvinge dårlige konfigurationer eller nulstille legitimationsoplysninger være skadelig og forstyrrende.
Sårbarhedsmekanik — hvordan problemet introduceres
Fra en udvikler- og gennemgangsperspektiv optræder denne klasse af fejl typisk, når:
- Et plugin eksponerer en AJAX-handling, REST-endpoint eller admin POST-håndterer, der udfører privilegerede opgaver.
- Koden kontrollerer, om en bruger er logget ind - men ikke om brugeren har tilstrækkelige kapabiliteter (f.eks. manage_options).
- En udvikler antager, at “autentificerede brugere er betroede” (almindelig fejlagtig antagelse).
- Koden mangler enten helt en nonce-kontrol, eller nonce'en verificeres ikke, før der udføres en destruktiv operation.
Typisk sårbar flow (konceptuelt):
- En endpoint er registreret (via admin-ajax.php, REST API eller plugin-sidehandler).
- Handleren læser anmodningsparametre og udfører en konfigurationsnulstilling.
- Handleren indeholder ingen kapabilitetskontrol (current_user_can) og ingen nonce-verifikation (check_admin_referer eller wp_verify_nonce).
- Enhver autentificeret session (Subscriber+) kan sende POST og udløse nulstillingen.
Hvor dette ofte sker:
- admin-ajax.php handlinger (wp_ajax_{action}) der er registreret uden kapabilitetskontroller
- REST-ruter der mangler ordentlige tilladelsescallbacks
- Formularhandlere på frontenden der kun tjekker is_user_logged_in()
Udnyttelighed og trusselmodel
Hvem kan udnytte det?
- Enhver autentificeret bruger med mindst Subscriber-rettigheder på WordPress-sitet.
- En angriber der har kompromitteret en lav-rettighedskonto, eller som kan oprette konti (åben registrering) og opnå abonnentstatus.
- CSRF-scenarier hvor en logget ind bruger bliver narret til at besøge en ondsindet side der laver baggrundsanmodninger.
Hvor nemt er det at udnytte?
- På sider med åben registrering: trivielt — en angriber registrerer sig og bruger kontoen.
- På lukkede registreringssider: udnyttelse er sværere men muligt hvis en angriber har en kompromitteret abonnentkonto (phishing, credential reuse).
- CSRF-risikoen er høj hvis plugin'et kun er afhængigt af is_user_logged_in() og mangler nonce-tjek, da en ondsindet webside kunne bruge offerets browser til at kalde endpointet.
Hvad kan en angriber opnå?
- Nulstille konfigurationen for en kalenderintegration (f.eks. fjerne eller ændre API-nøgler, synlighed).
- Gentagne nulstillinger for at forårsage forstyrrelse.
- Hvis der findes regressioner, kan nulstillingen resultere i eksponering eller yderligere brud (afhængigt af plugin'ets interne logik).
Udnyttelseseksempel (konceptuelt, ikke handlingsorienteret):
- POST til pluginens nulstillings-endpoint, inklusive de minimum krævede parametre, med sessionscookie.
- Anmodningen lykkes, fordi pluginen ikke verificerer opkalderens kapabilitet eller tjekker en nonce.
Vi deler ikke fungerende udnyttelsesscripts her.
Indikatorer for kompromis og hvordan man opdager misbrug
Hvis du mistænker udnyttelse, skal du se efter:
- Uventede ændringer i pluginens indstillinger: manglende API-nøgler, ændrede kalender-ID'er, flag der er tændt/slukket.
- Admin-e-mails eller systemmeddelelser om integrationsfejl (Google API OAuth genautentificering krævet).
- Gentagne lignende anmodninger i dine webserver-/applikationsadgangslogs, der retter sig mod admin-ajax.php eller pluginens specifikke endpoint.
- POST-anmodninger, der resulterer i en 200 OK med en besked, der angiver “nulstilling fuldført” eller lignende meddelelser.
- Øgede fejl-logs fra mislykkede kalender API-opkald (manglende legitimationsoplysninger efter nulstilling).
Søg disse logs:
- Webserver (nginx/apache) access.log for anmodninger til:
- /wp-admin/admin-ajax.php?action=…
- /wp-json/{plugin}/{route} (hvis pluginen eksponerer REST-ruter)
- /wp-admin/admin.php?page=private-google-calendars eller lignende
- WordPress debug.log for at se, om plugin-genererede meddelelser afslører nulstillinger
- Godkendelseslogs for nyregistrerede konti, mistænkelige loginmønstre eller samtidige logins fra forskellige IP'er (mulig konto-kompromittering)
Eksempel på logmønster at søge efter (konceptuelt):
- POST /wp-admin/admin-ajax.php?action=pgc_reset_settings 200
- ELLER POST /wp-json/private-google-calendars/v1/reset-settings 200
Hvis du finder mange lignende anmodninger fra forskellige IP'er ved hjælp af forskellige sessionscookies, kan det indikere automatiseret misbrug.
Øjeblikkelige afbødningstrin (site ejere)
- Opdater plugin'et
- Den definitive løsning er at opdatere Private Google Calendars til version 20251128 (eller senere). Den version inkluderer en autorisationsrettelse.
- Hvis du kan opdatere med det samme, så gør det. Test altid først på et staging-site, hvis du har komplekse integrationer.
- Hvis du ikke kan opdatere med det samme: midlertidige afbødninger
- Deaktiver nye brugerregistreringer, hvis du ikke har brug for dem (Indstillinger → Generelt → Medlemskab).
- Gennemgå abonnentkonti: fjern ukendte eller ubrugte abonnentkonti og roter legitimationsoplysninger for konti, du mistænker for at være kompromitteret.
- Skift Google API-legitimationsoplysninger, som plugin'et bruger, hvis du ser tegn på, at de er blevet nulstillet eller ændret. Tilbagekald tidligere nøgler/tokens og udsted nye.
- Indfør en kortvarig admin-only begrænsning på plugin-indstillingssider ved hjælp af et rolle-kapabilitets-plugin (begræns adgang til plugin-sider til administratorer kun).
- Brug en Web Application Firewall (WAF) / Virtuel patch med det samme
- Hvis du kører en WAF (som WP-Firewall's administrerede WAF), skal du aktivere regelsættet, der blokerer plugin'ets indstillings-nulstillings-endepunkter og blokerer anmodninger, der mangler gyldige nonces.
- Virtuel patching kan blokere angrebsvektoren, selvom du ikke kan opdatere plugin'et med det samme - se WAF-reglerne nedenfor.
- Kræv multifaktorautentifikation (MFA) for administrative konti
- Håndhæve MFA for alle konti på eller over redaktørrollen for at reducere risikoen for misbrug af legitimationsoplysninger.
- Overvågning
- Aktivér revisionslogning (eller installer et aktivitetslog-plugin) for at fange ændringer i plugin-indstillinger og hvem der initierede dem.
- Hold øje med usædvanlig admin-aktivitet og flere nulstillingsforsøg.
Virtuel patching med en Web Application Firewall - anbefalede regelmønstre
Mens kodefixer i plugin'et er den langsigtede løsning, kan en korrekt konfigureret WAF hurtigt afbøde udnyttelse. Nedenfor er mønstre og ideer til WAF-regler, der beskytter dit site uden at bryde legitim adfærd (test regler i staging, hvor det er muligt).
Vigtig: Tilpas disse regler til de faktiske handlinger eller rutenavne, der bruges af dit plugin på dit site.
A. Bloker opkald til nulstillingshandlingen fra ikke-admin kontekster
- Match anmodninger:
- Metode: POST
- URI: /wp-admin/admin-ajax.php
- Spørgestreng eller anmodningskropsparameter: action=private_gc_reset_settings (eller plugin'ets faktiske handlingsnavn)
- Betingelse: Hvis anmodningen ikke indeholder en gyldig admin nonce-parameter (f.eks. security=[nonce]) ELLER Referer ikke stammer fra dit sites admin-URL
- Handling: Bloker eller udfordring (403 eller CAPTCHA)
B. Kræv tilstedeværelse af nonce og mønster
- Match anmodninger til admin-ajax.php med plugin'ets handling OG nægt hvis der ikke er nogen nonce-parameter eller nonce-parameteren ikke matcher mønsteret [a-zA-Z0-9-_]{10,}
- Nogle WAF'er kan også validere nonce-værdier mod kendte gemte nonces, hvis de er integreret med WordPress — hvis tilgængeligt, valider server-side.
C. Beskyt REST-ruter
- Hvis plugin'et eksponerer REST-endepunkter som /wp-json/private-google-calendars/v1/reset:
- Bloker POST-anmodninger, medmindre de præsenterer en X-WP-Nonce-header, der validerer, eller anmodningen stammer fra admin-konteksten.
- Regel: Hvis POST til plugin REST-ruten og manglende X-WP-Nonce ELLER tilladelsescallback'en ville kræve manage_options, bloker.
D. Bloker anonyme CSRF-vektorer
- For front-end formularer, der kræver autentificerede brugere, bloker cross-site POSTs, der mangler en Origin eller Referer-header, der matcher dit domæne.
- Nægt POST-anmodninger med fraværende eller mismatched Referer for endepunkter, der kun skal indsendes fra admin-sider.
E. Rate-limite reset handlinger
- Anvend strenge rategrænser for reset-endepunktet pr. autentificeret konto og pr. IP (f.eks. maks 1 reset pr. 24 timer pr. konto).
- Hvis din WAF understøtter rate-limiting pr. konto ved hjælp af sessionscookies, vedhæft regler til sessionscookies.
F. Placering og sikker testning
- Udrul regler i kun-detekteringsmode først (log kun) i 24–48 timer for at sikre, at ingen legitime arbejdsgange blokeres. Skift derefter til blokering, når du er sikker.
- Giv en bypass-sti (midlertidig admin-hvidliste) for at tillade webstedets administratorer at få adgang til funktionaliteten, mens reglerne justeres.
Eksempel på pseudo-regel (konceptuel, ikke leverandørsyntaks):
HVIS request.method == POST OG request.uri == /wp-admin/admin-ajax.php OG request.params['action'] == 'pgc_reset_settings' OG IKKE request.params.contains('security') SÅ BLOKER
Kode-niveau fix vejledning for plugin-udviklere
Hvis du vedligeholder plugins, er mønsteret, du altid skal følge:
- Bekræft, at opkaldet har den rette kapabilitet (current_user_can).
- Bekræft en nonce (check_admin_referer eller wp_verify_nonce).
- Rens og valider input.
- Returner passende HTTP-statuskoder og beskeder for uautoriserede opkald.
Sikker eksempelhandler (konceptuel; tilpas navne til dit plugin):
add_action( 'wp_ajax_pgc_reset_settings', 'pgc_reset_settings' );
Ting at bemærke for plugin-forfattere:
- Brug en kapabilitet, der matcher operationen: nulstilling af plugin-konfiguration er typisk en administrator-aktion — kræv manage_options eller en brugerdefineret kapabilitet tildelt kun til administratorer.
- Nonce-navne skal være specifikke og handlingsbundne (se check_admin_referer brug til admin-formularer).
- Log administrative handlinger (hvem gjorde hvad og hvornår) for revisionsmuligheder.
- Dokumenter slutpunkter og tilladelsesforventninger klart.
Driftsanbefalinger og hårdningscheckliste
For webstedsejere og administratorer:
- Opdater plugins, så snart patches er tilgængelige; anvend på staging først, hvis nødvendigt.
- Reducer antallet af konti med forhøjede rettigheder. Brug rolleadministration til at håndhæve mindst privilegium.
- Begræns eller fjern offentlig brugerregistrering, medmindre det er nødvendigt. Tilføj e-mailverifikation og moderation, hvis det er nødvendigt.
- Håndhæv stærke adgangskoder og aktiver MFA for privilegerede brugere.
- Installer et aktivitets-/revisionsloggingsplugin for at opdage ændringer i plugin-indstillinger og administrative handlinger.
- Planlæg en tilbagevendende plugin-inventar og sårbarhedsscanning.
- Hold offsite sikkerhedskopier og en testet gendannelsesproces. Hvis du opdager misbrug, gendan fra en kendt god sikkerhedskopi, når det er nødvendigt.
- Brug netværksniveau beskyttelser: WAF, hastighedsbegrænsning og botblokering.
Til udviklere:
- Valider altid kapaciteter, nonces og sanitér input på enhver kodevej, der ændrer konfiguration eller bevarer tilstand.
- Brug kapacitetsbaserede tilladelsescallbacks til REST-ruter (permission_callback parameter).
- Tilføj automatiserede tests for håndhævelse af tilladelser (enheds- og integrationstests).
- Log og revider følsomme handlinger.
Hvordan WP-Firewall hjælper
Hos WP-Firewall fokuserer vi på at give webstedsejere praktiske, umiddelbare beskyttelser ud over langsigtet hærdningsvejledning:
- Administreret Web Applikation Firewall (WAF): Vores administrerede WAF kan implementere målrettede virtuelle patches for at blokere udnyttelsesforsøg mod kendte pluginfejl, mens du planlægger en opdatering. Til dette problem anbefaler vores team en regel, der blokerer anmodninger, der forsøger at kalde pluginets nulstillingshandling uden en gyldig nonce eller fra ikke-administrator referencer.
- Malware-scanner & integritetskontroller: Vores scanner overvåger pluginfiler og indstillinger for ændringer, der indikerer manipulation eller masse-nulstillinger.
- OWASP Top-10 afbødninger: Den administrerede firewall og scanningssuite inkluderer beskyttelser, der reducerer eksponeringsvinduet for almindelige risikoklasser som Brudt Adgangskontrol og Cross-Site Request Forgery.
- Automatisk virtuel patching (for Pro-kunder): Vi kan implementere midlertidige signaturer, der blokerer kendte udnyttelsestrafikmønstre for sårbarheden, indtil en leverandørpatch er anvendt.
- Logs, alarmer og rapporter: Vi leverer handlingsbare logs og alarmer, når mistænkelige anmodninger blokeres, og månedlig sikkerhedsrapportering i højere niveauer.
- Administreret hjælp: Hvis du har brug for hurtig hændelsesrespons, kan vores team hjælpe med at analysere logs, foreslå indholdstrin og hjælpe dig med at gendanne korrekte indstillinger.
Hvis du er på et begrænset vedligeholdelsesvindue, er virtuel patching via WP-Firewall et praktisk mellemtrin — det giver dig tid til at planlægge en sikker opdatering og regressionstest.
Beskyt dit WordPress-websted lige nu — start med en gratis plan
Beskyt hjertet af dit websted — start med essentiel beskyttelse
Hvis du ønsker øjeblikkelig baselinebeskyttelse, som du kan aktivere lige nu, leverer WP-Firewalls Basic (Gratis) plan essentielle forsvar, der stopper mange automatiserede og målrettede angreb. Den gratis plan inkluderer en administreret firewall, ubegribelig båndbredde til webstedstrafik, en robust Web Application Firewall (WAF), en malware-scanner og afbødning af OWASP Top-10 risici. Det er en praktisk første forsvarslinje, mens du planlægger plugin-opdateringer eller udfører hændelsesrespons.
Tilmeld dig den gratis plan her:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Opgradering til Standard eller Pro låser op for automatisk malwarefjernelse, IP-blacklisting/hvidlisting, månedlige sikkerhedsrapporter og automatiseret virtuel patching for kendte sårbarheder — nyttigt hvis du driver flere websteder eller har brug for kontinuerlig overvågning og hurtig afhjælpning.
Detektion, logføring og efter-hændelses trin
- Rotér straks relevante API-legitimationsoplysninger (Google API-nøgler, OAuth-tokens) og genautoriser integrationer.
- Gennemgå aktivitetslogs for at identificere den brugerkonto, der blev brugt til nulstillingen. Lås og nulstil den kontos adgangskode og tving en gen-login.
- Fjern eventuelle uautoriserede abonnentkonti og undersøg webstedregistreringer.
- Gendan plugin-indstillinger fra en sikkerhedskopi, hvis du har en, og bekræft den forventede konfiguration.
- Patch pluginet til den faste version (20251128 eller senere).
- Overvej at rotere andre hemmeligheder og tjekke for lateral bevægelse — en nulstilling kunne have været en del af en større målrettet kampagne.
Udviklernote: hvorfor kapabilitetskontroller er vigtige
Kapabiliteter i WordPress adskiller konceptet om en autentificeret bruger (is_user_logged_in()) fra en autoriseret bruger (current_user_can()). For handlinger, der ændrer webstedets tilstand, skal du kun stole på kapabiliteter; behandl ikke at være logget ind som tilstrækkeligt. Nonces beskytter mod cross-site request forgery; både kapabilitetskontroller og nonce-verifikation er standard bedste praksis.
Tidslinje & kredit
- Sårbarhed offentliggjort: 2026-02-02
- Rapporteret af: Athiwat Tiprasaharn (Jitlada)
- CVE: CVE-2025-12526
- Berørte versioner: <= 20250811
- Rettet i: 20251128
Vi takker forskeren for ansvarligt at rapportere dette problem. Ansvarlig offentliggørelse og hurtig patching er den hurtigste måde at reducere risikoen i hele WordPress-økosystemet.
Afsluttende anbefalinger (hurtig tjekliste)
- Opdater Private Google Kalendere til 20251128 (eller senere) — højeste prioritet.
- Hvis du ikke kan opdatere med det samme:
- Deaktiver åben registrering midlertidigt.
- Revider abonnentkonti.
- Brug WP-Firewall til at anvende en virtuel patch (blokér nulstillings-endpoint eller kræv nonces).
- Rotér API-legitimationsoplysninger, hvis du ser tegn på manipulation.
- Håndhæve MFA og mindst privilegium for alle brugere med forhøjede kapabiliteter.
- Overvåg logfiler for POST-anmodninger til admin-ajax.php eller REST-endepunkter relateret til plugin'et.
- Implementer de plugin-udviklerløsninger, der er beskrevet ovenfor for enhver brugerdefineret kode.
Afsluttende tanker
Denne sårbarhed er en nyttig påmindelse om, at selv tilsyneladende små designfejl (forudsat at autentificerede brugere automatisk er autoriserede) kan skabe driftsproblemer. Brud på adgangskontrol er en hyppig årsag til privilegiumseskalering eller misbrug i WordPress-plugins. Løsningen er ligetil: kræv en passende kapabilitet og verificer en nonce for enhver handling, der ændrer konfiguration eller udfører følsomme tilstandsændringer.
Hvis du har brug for hjælp til at vurdere dine websteder, implementere midlertidige WAF-regler eller gennemføre en efter-hændelse-gennemgang, kan vores WP-Firewall-team hjælpe — vi tilbyder både automatiserede beskyttelser og menneskestyret afhjælpningssupport. Start med den gratis plan for at få øjeblikkelig beskyttelse og se, hvordan administreret firewall og scanning reducerer din eksponering, mens du opdaterer plugins og styrker dit miljø.
Hold dig sikker og hold dit websted opdateret.
— WP-Firewall Sikkerhedsteam
