Lämna dina kontaktuppgifter, så skickar vi dig vår översikt via e-post
Jag samtycker till att mina personuppgifter behandlas för att skicka personligt marknadsföringsmaterial i enlighet med integritetspolicy. Genom att bekräfta inlämningen samtycker du till att få marknadsföringsmaterial
Tack!

Formuläret har skickats in framgångsrikt.
Ytterligare information finns i din brevlåda.

Data AI Mobilappar Finans Biovetenskap ERP
Innowise logo
Om oss
Tjänster
Teknik
Branscher
Portfölj
Flash hire iconAnlita oss Flash hire iconAnlita oss
Kontakta oss Kontakta oss
SV
Hur vi arbetar Kvalitetsledning Säkerhetshantering Företagens sociala ansvar Ledarskap Våra experter Blogg Experttips
Kundrecensioner Tekniska partners Certifieringar Utmärkelser Evenemang Nyhetsrum
In-house vs outsourcing mjukvaruutveckling 2026: fördelar, nackdelar, kostnader & hur man väljer
Läs artikeln
Tjänster för utveckling av programvara i hela cykeln
IT-konsultationer och rådgivning Webbutveckling Mobil utveckling Utveckling av inbyggd programvara Anpassad mjukvaruutveckling MVP-utveckling Cloud development ERP-utveckling Stöd för stordatorer Modernisering av äldre system
 
UI/UX design 3D-konstruktion Programvarutestning och kvalitetssäkring Säkerhetstestning Databasadministration DevOps DevSecOps Nätverk IT staff augmentation Dedikerat team
Implementering av avancerad teknik
Big data Hantering av data Dataanalys Data engineering Datavisualisering Business intelligence Maskininlärning Artificiell intelligens Datavetenskap Hållbarhet & ESG

Digital transformation Automatisering av affärsprocesser Robotbaserad processautomation Cybersäkerhet Sakernas internet Blockchain NFT Metaverse AR& VR
Front-end
React Angular Vue.js JavaScript
Back-end
Java .NET Python PHP Rust C/C++
 
Node.js Unity Ruby Golang Unreal Engine Cobol
Mobilappar
iOS Android Flutter React Native Xamarin .NET MAUI
 
Swift Kotlin
Cloud
AWS Azure GCP Sharepoint
ERP & CRM-
SAP MS Dynamics 365 Odoo Salesforce Creatio
Finans Bank Handel Försäkring e‑handel Detaljhandel
Vård Farmaci Utbildning Telekommunikation Media & Underhållning
Företag Tillverkning Fordonsindustrin Logistik Transport Marknadsföring Reklam
Offentlig sektor Energi & Försörjningstjänster Olja & Gas Bygg Fastigheter Jordbruk Resor
Kundcase
Bank Finans Vård Läkemedel
E-handel Detaljhandel Tillverkning Företag
Våra plattformar
System för uppföljning av sökande (ATS) HRM-system System för hantering av lärande (LMS) System för bokning av arbetsplatser
Ett enhetligt AI-baserat finansiellt operativsystem för fiatvalutor och kryptovalutor
Läs fallstudie
Anlita dedikerade utvecklare
IT staff augmentation Dedikerade team Offshore-utvecklare
Anlita webbutvecklare
Angular React.js Vue.js JavaScript Ruby on Rails Full stack MEAN stack
.NET Java PHP Python Golang Cobol
Anlita mobilutvecklare
iOS Android Kotlin React Native Swift
Anlita andra ingenjörer
AI Cloud AWS Azure DevOps QA
Fintech SAP Odoo Salesforce Shopify UiPath
Data AI Mobilappar Finans Biovetenskap ERP
Innowise logo
Om oss
Tjänster
Teknik
Branscher
Portfölj
Flash hire iconAnlita oss
Kontakta oss
sv Svenska

Välj språk

Mobile menu arrow iconOm oss
Om oss
Hur vi arbetar Kvalitetsledning Säkerhetshantering Företagens sociala ansvar Ledarskap Våra experter Blogg Experttips
Kundrecensioner Tekniska partners Certifieringar Utmärkelser Evenemang Nyhetsrum
In-house vs outsourcing mjukvaruutveckling 2026: fördelar, nackdelar, kostnader & hur man väljer
Läs artikeln
Mobile menu arrow iconTjänster
Alla tjänster
Tjänster för utveckling av programvara i hela cykeln
IT-konsultationer och rådgivning Webbutveckling Mobil utveckling Utveckling av inbyggd programvara Anpassad mjukvaruutveckling MVP-utveckling Cloud development ERP-utveckling Stöd för stordatorer Modernisering av äldre system
UI/UX design 3D-konstruktion Programvarutestning och kvalitetssäkring Säkerhetstestning Databasadministration DevOps DevSecOps Nätverk IT staff augmentation Dedikerat team
Implementering av avancerad teknik
Big data Hantering av data Dataanalys Data engineering Datavisualisering Business intelligence Maskininlärning Artificiell intelligens Datavetenskap Hållbarhet & ESG
Digital transformation Automatisering av affärsprocesser Robotbaserad processautomation Cybersäkerhet Sakernas internet Blockchain NFT Metaverse
AR &VR
Mobile menu arrow iconTeknik
Alla tekniker
Front-end
React Angular Vue.js JavaScript
Back-end
Java .NET Python PHP Node.js Unity Ruby Golang Rust C/C++ Unreal Engine Cobol
Mobilappar
iOS Android Flutter React Native Xamarin .NET MAUI Kotlin Swift
Cloud
AWS Azure GCP Sharepoint
ERP & CRM-
SAP MS Dynamics 365 Odoo Salesforce Creatio
Mobile menu arrow iconBranscher
Alla branscher
Finans Bank Handel Försäkring e‑handel Detaljhandel
Vård Farmaci Utbildning Telekommunikation Media & Underhållning
Företag Tillverkning Fordonsindustrin Logistik Transport Marknadsföring Reklam
Offentlig sektor Energi & Försörjningstjänster Olja & Gas Bygg Fastigheter Jordbruk Resor
Mobile menu arrow iconPortfölj
Portfölj
Kundcase
Bank Finans Vård Läkemedel
E-handel Detaljhandel Tillverkning Företag
Våra plattformar
System för uppföljning av sökande (ATS) HRM-system System för hantering av lärande (LMS) System för bokning av arbetsplatser
Ett enhetligt AI-baserat finansiellt operativsystem för fiatvalutor och kryptovalutor
Läs fallstudie
Mobile menu arrow icon Anlita oss
Anlita oss
Anlita dedikerade utvecklare
IT staff augmentation Dedikerade team Offshore-utvecklare
Anlita webbutvecklare
Angular React.js Vue.js JavaScript Ruby on Rails Full stack MEAN stack .NET Java PHP Python Golang Cobol
Anlita mobilutvecklare
iOS Android Kotlin React Native Swift
Anlita andra ingenjörer
AI Cloud AWS Azure DevOps QA Fintech SAP Odoo Salesforce Shopify UiPath

Säkerhetschecklista för PHP: 8 steg för att upptäcka och åtgärda sårbarheter

5 november 2026 19 min läsning
php icon.
Herman Samolazov, Head of Engineering..
Av Herman Samolazov
Chef för Engineering
Verifierad expert
Varje artikel på Innowise är skriven av författare med praktisk erfarenhet. De har en förståelse för ämnet som sträcker sig bortom teorin och bidrar med insikter från verkliga projekt.
7+ års erfarenhet
Verifierad expert
7+ års erfarenhet
Herman leder teknikavdelningar och utformar de processer, teamstrukturer och tekniska standarder som krävs för att de ska kunna växa. Hans expertis omfattar backend-system med hög belastning, leveranshantering och ledarskap inom teknikområdet.
Expertis
System för hög belastning Programvaruarkitektur Databaser
Publicerad i
Medium logo.
Låt oss prata

Viktiga punkter

  • PHP2Shell kräver omedelbar uppdatering. Den 21 oktober 2026 åtgärdade PHP CVE-2026-109618 och CVE-2026-109619. Båda är kritiska sårbarheter i körmiljön (CVSS v4.0: 9,2) som kan möjliggöra obehörig fjärrkörning av kod.
  • Kontrollera de uppdaterade versionerna. De första utgåvorna med korrigeringar är PHP 8.2.35, 8.3.36, 8.4.27 och 8.5.12. Linux-distributioner kan tillhandahålla samma korrigeringar via bakåtportade patchar.
  • Prioritera utsatta PHP-körmiljöer. Apache mod_php medför den högsta rapporterade risken, men PHP-FPM och andra webbbaserade konfigurationer kräver också uppmärksamhet. Uppdateringar av ramverk och granskning med Composer åtgärdar inte PHP2Shell.
  • Nöj dig inte med att patcha PHP. Använd checklistan med åtta steg för att granska beroenden, applikationskod, serverinställningar och andra säkerhetsbrister.
  • Verifiera åtgärden i produktionsmiljön. Be ditt team om en rapport som visar vilka PHP-versioner som faktiskt körs, vilka arbetsbelastningar som har patchats och om det finns tecken på tidigare intrång.
Sammanfatta artikeln med AI
Lägg till bland favoritkällorna

Enligt W3Techs, PHP används på cirka 70 % av webbplatserna där det är känt vilket språk som används på serversidan. Eftersom PHP är så vanligt kan en sårbarhet i tolken utsätta många webbplatser för risk, även om deras egen kod är säker.

Den 21 oktober 2026 släppte PHP-projektet nödkorrigeringar för två kritiska sårbarheter, CVE-2026-109618 och CVE-2026-109619, som tillsammans kallas PHP2Shell. Båda fick betyget 9,2 enligt CVSS v4.0 och möjliggör obehörig fjärrkörning av kod. Dessa sårbarheter påverkar PHP:s interna minne och hanteringen av förfrågningar.

De första säkerhetsuppdateringarna släpptes i PHP 8.2.35, 8.3.36, 8.4.27 och 8.5.12. Om ditt system använder någon av de drabbade versionerna bör du omedelbart uppdatera PHP och se till att din webbserver kör den uppdaterade versionen. Men arbetet bör inte sluta där. För team som bygger och underhåller PHP-applikationer, inklusive Innowises PHP-utvecklingsspecialister, är oktoberutgåvan också ett tillfälle att granska beroenden, applikationskod och serverinställningar.

I den här guiden visar jag dig åtta steg för att hitta och åtgärda sårbarheter i din PHP-miljö och bekräfta att dina korrigeringar fungerar i produktionsmiljön.

Se vilka relaterade tjänster vi erbjuder

Analys av experter: hur PHP2Shell skiljer sig från en vanlig beroendebaserad CVE

Ett sårbart Composer-paket påverkar kod som din applikation använder. PHP2Shell är annorlunda. Båda sårbarheterna finns inuti själva PHP-tolken, och en angripare kan utlösa dem innan Laravel, Symfony eller ett annat ramverk ens har börjat köras. Att uppdatera CMS-plugins eller Composer-beroenden kommer inte att åtgärda PHP, och composer audit kommer inte att upptäcka dessa sårbarheter under körning.

PHP-säkerhetsteamet identifierar Apache mod_php som den konfiguration som medför högst risk för CVE-2026-109618, med en demonstrerad attack som fungerar innan applikationskoden körs. PHP-FPM, CGI och andra webbserverkonfigurationer påverkas också, även om förutsättningarna för utnyttjande skiljer sig åt. Forskare har även demonstrerat utnyttjande av CVE-2026-109619 mot PHP-FPM.

Så här går det fel i respektive fall:

CVEGrundorsakVarför teamen bör bry sig om detta
CVE-2026-109618Om PHP får slut på minne under bearbetningen av en begäran kan vissa interna data hamna i ett ogiltigt tillstånd. När PHP rensar upp den misslyckade begäran kan det hända att programmet använder dessa data.Om PHP får slut på minne under bearbetningen av en begäran kan vissa interna data hamna i ett ogiltigt tillstånd. När PHP rensar upp den misslyckade begäran kan det hända att programmet använder dessa data.
CVE-2026-109619En PHP-arbetsprocess kan behålla en referens till minne som frigjorts efter en tidigare begäran. När arbetsprocessen hanterar en annan begäran kan den försöka använda den gamla referensen.Problemet kan överföras mellan förfrågningar som hanteras av samma worker. Att kontrollera enskilda applikationsförfrågningar behöver inte nödvändigtvis avslöja detta.

Båda sårbarheterna kan leda till att kod körs på distans utan autentisering. Åtgärden ska göras i PHP-körmiljön, inte i applikationens beroenden.

För en mer ingående teknisk förklaring kan du läsa PHP-projektets säkerhetsmeddelanden för CVE-2026-109618 och CVE-2026-109619.

Varifrån kommer PHP-säkerhetsbristerna?

Som jag nämnde tidigare löser en uppdatering av PHP inte problemet med ett sårbart Composer-paket, och en ren beroendeskanning upptäcker inte problem i din egen kod. När jag granskar en PHP-applikation tittar jag på fyra källor till säkerhetsrisker, var och en med sina egna potentiella konsekvenser.

KategoriExempelHuvudsaklig risk
PHP-körmiljöOuppdaterade PHP-versioner, sårbarheter i tolken, versioner som inte längre stödsAngripare utnyttjar sårbarheter i PHP självt, oavsett hur säkert programmet är skrivet
Beroenden av tredje partKompositörspaket, CMS-plugins, ramverkSårbar kod från tredje part utsätter applikationer för attacker även om din egen kod är säker
ApplikationskodSQL-injektion, XSS, CSRF, osäker deserialisering, bristfällig åtkomstkontrollFel i kodningen kan göra det möjligt för angripare att stjäla data, utföra obehöriga åtgärder eller äventyra applikationens säkerhet
Konfiguration och infrastrukturOsäkra PHP-inställningar, exponerade filer, för omfattande behörigheterFelaktiga inställningar kan leda till att känslig information exponeras eller att angripare får större åtkomst än avsett

Åtgärda PHP-sårbarheter innan de förvärras

Kontakta en expert

Säkerhetslista för PHP: 8 viktiga kontroller

Låt oss nu gå igenom åtta säkerhetskontroller som jag skulle använda för en befintlig PHP-applikation. Jag skulle börja med PHP-körmiljön som hanterar liveförfrågningar och sedan granska koden, beroenden och konfigurationen för att upptäcka problem som en PHP-uppdatering inte räcker för att åtgärda.

Kontrollera din PHP-version och säkerhetsuppdateringar

Identifiera först vilka PHP-körmiljöer dina applikationer använder: Apache mod_php, PHP-FPM, php-cgi, FrankenPHP eller LiteSpeed. Inkludera separata FPM-pooler, containrar, CLI-installationer, köarbetare och schemalagda jobb.

Lita inte enbart på php -v eller php –ini. php -v visar CLI-versionen, medan php –ini visar dess konfiguration. Inget av dem bekräftar vilken PHP-körmiljö som hanterar webbförfrågningar.

Jämför den aktiva körmiljön och dess konfiguration med officiella PHP-säkerhetsmeddelandet, inklusive berörda versioner och exponeringsförhållanden. Apache mod_php har den starkast påvisade PHP2Shell-sårbarheten, inklusive en exploateringsväg innan applikationskoden körs. PHP-FPM-sårbarheten beror på konfiguration och körvägar. Andra SAPI:er behöver också utvärderas, eftersom SAPI:n i sig inte avgör om en distribution är säker.

De första uppströmsutgåvorna som innehöll båda korrigeringarna var:

PHP-grenenFörsta stabila versionen
8.28.2.35
8.38.3.36
8.48.4.27
8.58.5.12

Dessa versioner listas i PHP-säkerhetsmeddelandena för CVE-2026-109618 och CVE-2026-109619. Kontrollera om det finns nyare säkerhetsuppdateringar innan du uppdaterar.

Kontrollera PHP-korrigeringar på Linux och i containrar

Kontrollera den aktiva runtime-miljön. Granska din webbserverkonfiguration för att identifiera PHP-modulen, FPM-poolen eller den inbäddade SAPI:n som hanterar förfrågningar. Bekräfta versionen med hjälp av åtkomstbegränsad diagnostik och ta bort eventuella tillfälliga ändpunkter efteråt. Exponera aldrig phpinfo() eller en versionsändpunkt offentligt.

Kontrollera installerade paket. På Ubuntu med PHP 8.3 visar dessa skrivskyddade kommandon installerade paket och tillgängliga versioner:

dpkg-query -W 'php8.3*'
apt-cache policy php8.3-fpm

Anpassa paketnamnen efter din PHP-gren och jämför de installerade versionerna med leverantörens säkerhetsmeddelande eller paketets ändringslogg. Linux-leverantörer kan backporta korrigeringar till äldre PHP-versioner. Ubuntu listar till exempel följande uppdaterade versioner:

  • Ubuntu 24.04: 8.3.6-0ubuntu0.24.04.13

  • Ubuntu 22.04: 8.1.2-1ubuntu2.28

Båda innehåller de relevanta korrigeringarna trots sina lägre versionsnummer. Kontrollera Ubuntus säkerhetsmeddelande.

Korrigera och distribuera på nytt. Installera de korrigerade paketen. För containrar ska du registrera hashvärdet för den körande bilden, uppdatera sårbara PHP-basbilder, bygga om och distribuera på nytt berörda arbetsbelastningar, inklusive köarbetare.

Verifiera resultatet. Starta om eller byt ut berörda PHP-arbetare och bekräfta att körande processer och containrar använder uppdaterade versioner eller verifierade leverantörsbackports. Dokumentera paketversioner, digester för den körande bilden, detaljer om omstart och verifieringsresultat.

PHP 8.1 och tidigare versioner stöds inte längre uppströms, även om vissa leverantörer fortfarande tillhandahåller säkerhetsbackports. Kontrollera om din installerade version omfattas och uppgradera om så inte är fallet. Säkerhetsstödet för PHP 8.2 upphör den 31 december 2026, så kombinera eventuella kortsiktiga patchar med en uppgraderingsplan. Du hittar den fullständiga tidsplanen för support i PHP-supportschemat.

Granska beroenden och ramverk

Börja med composer.lock. Den innehåller information om vilka paketversioner din applikation är beroende av, inklusive de som installeras indirekt via andra paket. Kör dessa två kommandon:

composer audit --locked
composer outdated

composer audit --locked kontrollerar de låsta versionerna mot kända säkerhetsmeddelanden och kan markera övergivna paket. composer outdated visar vilka uppdateringar som finns tillgängliga, men ett föråldrat paket är inte nödvändigtvis sårbart. Kontrollera även Laravel eller Symfony-säkerhetsmeddelanden, särskilt om din ramverksversion inte längre stöds.

Jämför de paket som är driftsatta i produktionsmiljön med versionerna i den granskade låsfilen. Spara granskningsresultaten och inventeringen av installerade paket tillsammans med dina release-dokument.

Om du hittar sårbara paket, uppdatera dem till kompatibla, patchade versioner och testa den berörda funktionaliteten. Byt ut bibliotek som inte längre får säkerhetsuppdateringar. Om kompatibilitetsproblem hindrar en uppgradering av ramverket ska du dokumentera dessa samt det migreringsarbete som krävs. Glöm inte bort CMS-plugins eller bibliotek som är installerade utanför Composer.

En godkänd Composer-granskning bekräftar inte att PHP2Shell är åtgärdat. Granskningen kontrollerar Composer-paket, medan PHP2Shell kräver en separat kontroll av PHP-tolken och dess patchar. För att utvärdera själva applikationen, använd SAST för att analysera källkoden och DAST för att testa den körande applikationen.

Granska PHP och serverkonfigurationer

Kontrollera vilka PHP-inställningar som faktiskt används av din webbserver, inklusive PHP-FPM-poolens överskrivningar och laddade tillägg. Kom ihåg att php --ini visar CLI-konfigurationen, som kan skilja sig från den aktiva applikationen.

För produktion, börja med:

display_errors = Off
log_errors = On

Förvara loggar utanför offentligt tillgängliga kataloger och begränsa åtkomsten till dem. Ta bort offentliga phpinfo()-sidor och felsökningsändpunkter, och granska expose_php, onödiga tillägg och filsystembehörigheter.

Att inaktivera display_errors minskar informationsläckage, men minskar inte risken för CVE-2026-109619. Den sårbara kodvägen kan köras innan PHP hanterar felmeddelandet.

Tillfälliga åtgärder när PHP-uppdateringen försenas

Om uppdateringen måste vänta, följ officiella PHP-rekommendationen för din konfiguration.

  • CVE-2026-109619: Inaktivera session.upload_progress.enabled och, i PHP 8.5, ställ in fatal_error_backtraces=0. Tillämpa dessa inställningar innan begäranden bearbetas via server- eller poolkonfigurationen och starta sedan om berörda arbetare. Andra utnyttjningsvägar kan kvarstå.

  • CVE-2026-109618: Tillämpa memory_limit=-1 på server- eller poolnivå och starta om berörda arbetare. Detta eliminerar den förutsägbara PHP-vägen för minnesgränsfel, men andra allokeringsfel kan fortfarande förekomma. Kontrollera begärandegränser och minnesskydd för värd eller container för att minska risken för överbelastningsattacker.

PHP har också publicerat en separat rådgivande meddelande för CVE-2026-115560 den 23 oktober. Det gäller applikationer som byter session.serialize_handler från php_binary eller php_serialize till php med hjälp av ini_set() före session_start(), med uppladdningsförlopp aktiverat. Berörda installationer bör inaktivera uppladdningsförloppet i väntan på en korrigering.

Skaffa en uppgraderingsplan för de äldre PHP-applikationerna som ditt företag är beroende av

Kontakta oss

Kontrollera om det förekommer SQL-injektion, XSS och körning av osäker kod

Om användarinmatning hanteras på ett bristfälligt sätt kan känsliga uppgifter exponeras eller angripare få möjlighet att köra skadlig kod. Jag rekommenderar att du använder kodgranskning för att spåra riskfyllda inmatningsvägar och SAST för att upptäcka eventuella sårbarheter. Autentiserad DAST testar den körande applikationen, medan penetrationstestning hjälper till att avgöra vilka svagheter angripare skulle kunna utnyttja. Appar som byggts genom vibe-kodning kan ha samma brister och behöver samma kontroller.

SQL-injektion

SQL-injektion uppstår när användarinmatning förändrar strukturen på en databasfråga. Kontrollera hur din applikation bygger upp frågor, särskilt i sökformulär och rapporter.

För att hålla användarinmatningen åtskild från SQL-kommandon, använd PDO:s förberedda satser:

$stmt = $pdo->prepare(
    'SELECT id FROM users WHERE email = :email'
);
$stmt->execute(['email' => $email]);

Förberedda satser håller datavärdena åtskilda från SQL-syntaxen, precis som platshållaren :email gör i exemplet. Men platshållare kan inte representera tabell- eller kolumnnamn. Om användare till exempel kan sortera en rapport, välj då de tillåtna kolumnerna från en lista som definierats i applikationen. Testa de berörda frågorna efter att du har gjort ändringar.

Cross-site scripting

Cross-site scripting (XSS) uppstår när en applikation visar opålitliga data som en webbläsare kan köra som kod. Kontrollera PHP-mallar för användarinmatning som visas utan korrekt escapning, särskilt där automatisk escapning är inaktiverad.

Om din applikation till exempel visar ett användarnamn som HTML-text, använd htmlspecialchars() för att konvertera specialtecken så att webbläsaren behandlar dem som text:

echo htmlspecialchars(
    $name,
    ENT_QUOTES | ENT_SUBSTITUTE,
    'UTF-8'
);

Vilket skydd som är lämpligt beror på var data visas. JavaScript, URL:er och HTML-attribut kräver kontextspecifika kontroller och kodning. Om användare kan skicka in formaterad HTML, använd en HTML-sanitizer för att ta bort osäkra element samtidigt som tillåten formatering behålls.

Osäker kod och kommandokörning

Some PHP functions can execute system commands or PHP code. Check whether untrusted input reaches exec(), shell_exec(), or eval(). Also review dynamic file inclusion and the use of unserialize() with data from untrusted sources.

Where possible, use a PHP API instead of running a shell command. If you need to start an external program, specify the executable and pass its arguments separately. Here’s an example using Symfony Process:

use Symfony\Component\Process\Process;

// Validate $filePath against approved paths first.
$process = new Process([
    '/usr/bin/file',
    '--',
    $filePath
]);
$process->mustRun();

This example uses the file utility to identify a file’s type. Symfony Process passes $filePath as a separate argument rather than inserting it into a shell command string. You still need to validate the path, restrict the service account’s filesystem access, and allow only the operations your application requires.

Deserialization needs a separate check. Avoid passing untrusted data to unserialize(), even with allowed_classes restrictions. Where suitable, use JSON instead and validate the decoded values.

Översikt över autentisering, sessioner och åtkomstkontroll

Börja med lösenord. De bör inte lagras i läsbar form. Kontrollera att din applikation använder PHP:s password_hash() och password_verify(), eller motsvarande metoder i ditt ramverk. Leta efter äldre hash-kod som kanske inte längre är säker.

Därefter ska du kontrollera vad som händer när någon loggar in. Applikationen bör generera ett nytt sessions-ID så att ett ID som erhållits före inloggningen inte kan återanvändas för att få åtkomst till kontot. Granska inställningarna för session.use_strict_mode och cookies, såsom Secure, HttpOnly och SameSite. Testa regenereringen av sessions-ID via ditt ramverk, även när flera förfrågningar anländer samtidigt.

Nu ska du testa om användare kan se data som inte tillhör dem. Skapa två testkonton, vart och ett med sin egen faktura. Logga in på det första kontot och ändra faktura-ID:t i en begäran till det som tillhör det andra kontot. Servern ska neka åtkomst om inte den användaren har behörighet.

Upprepa testet för redigering av fakturor, nedladdning av filer och API-förfrågningar. Kontrollera att vanliga användare inte kan komma åt administratörsfunktioner. Att vara inloggad ger inte automatiskt någon behörighet att komma åt alla poster. Servern måste kontrollera behörigheterna för varje förfrågan till en skyddad post eller API-ändpunkt.

Kontrollera CSRF-skyddet

En CSRF-attack lurar webbläsaren hos en inloggad användare att utföra en åtgärd som denne inte har godkänt, till exempel att ändra kontouppgifter. Börja med att kontrollera formulär och förfrågningar som ändrar data, särskilt sådana som autentiseras via sessionscookies.

Granska CSRF-skyddet i din Laravel- eller Symfony-applikation och kontrollera om några rutter är undantagna. Där tokenvalidering tillämpas, testa förfrågningar med saknade eller ogiltiga token. Kontrollera också att förfalskade förfrågningar från en annan webbplats inte kan ändra användardata. Kontrollera även inställningen SameSite för sessionscookies.

I Laravel Blade lägger @csrf till ett dolt tokenfält i ett formulär:


    @csrf

Det finns en viktig detalj i Laravel 13. Dess CSRF-middleware kontrollerar först Sec-Fetch-Site-huvudet. En begäran från samma ursprung kan godkännas utan token, medan andra begäranden som standard faller tillbaka på tokenvalidering. Laravel inaktiverar också CSRF-skyddet som standard under automatiserade tester, så se till att det är aktiverat när du testar dessa skyddsmekanismer.

För API:er spelar autentiseringsmetoden roll. Ett tillståndslöst API som använder bearer-token i auktoriseringsrubriker utsätts i allmänhet för andra CSRF-risker. Men om din SPA förlitar sig på sessionscookies behöver den fortfarande skydd mot förfalskade förfrågningar.

Säker filöverföring och filåtkomst

Filuppladdningar utgör en säkerhetsrisk när angripare kan ladda upp körbara filer eller få tillgång till data som de inte borde se. Kontrollera vilka filtyper och filstorlekar din applikation accepterar, var uppladdningarna lagras och vem som kan ladda ner dem. Testa uppladdnings- och nedladdningsvägar för sökvägsgenomgång, se till att uppladdade filer inte kan köras som PHP och kontrollera att .env, .git och säkerhetskopieringsfiler inte är offentligt tillgängliga.

Nedan följer ett PHP-exempel som kontrollerar en uppladdad fils MIME-typ och sparar den under ett slumpmässigt genererat namn:

if (($_FILES['file']['error'] ?? null) !== UPLOAD_ERR_OK) {
    throw new RuntimeException('Uppladdningen misslyckades');
}

$tmp = $_FILES['file']['tmp_name'];
$allowed = ['image/jpeg' => 'jpg', 'image/png' => 'png'];
$mime = (new finfo(FILEINFO_MIME_TYPE))->file($tmp);

if (!isset($allowed[$mime])) {
    throw new RuntimeException('Filtyp stöds inte');
}

$name = bin2hex(random_bytes(16)) . '.' . $allowed[$mime];
$target = '/var/app/private-uploads/' . $name;

if (!move_uploaded_file($tmp, $target)) {
    throw new RuntimeException('Det går inte att spara uppladdningen');
}

Exemplet utgår från att en enskild fil laddas upp och att det finns en befintlig, privat katalog med lämpliga behörigheter. PHP:s move_uploaded_file() bekräftar att källfilen laddades upp via PHP:s HTTP POST-mekanism.

Enbart MIME-kontroll räcker inte för att göra uppladdningar säkra. Produktionskod behöver också serverbaserade begränsningar för filstorlek, behörigheter för upp- och nedladdning samt validering av det faktiska filinnehållet. Omkod bilder där det är lämpligt och överväg skanning efter skadlig kod för uppladdningar med högre risk. Förvara filer utanför webbrotkatalogen där det är praktiskt möjligt, begränsa åtkomsten till filsystemet och förhindra att uppladdade filer körs som PHP.

Skydda känsliga uppgifter och inloggningsuppgifter

Databaslösenord, API-nycklar och åtkomsttoken som läckt ut kan ge angripare tillgång till din applikation eller känslig data. Kontrollera din källkod och Git-historik för att se om dessa hemligheter finns där. Verktyg som Gitleaks kan hjälpa dig att hitta dem. Se till att .env-filer inte lagras i Git eller är tillgängliga via webben. Granska också vem som har åtkomst till hemligheter i CI/CD-pipelines och kontrollera containerbilder och applikationsloggar för känslig information.

Förvara hemligheter i en hemlighetshanterare eller ett annat system med begränsad åtkomst, snarare än i applikationskoden. Begränsa vem som kan visa eller ändra dem, och ge varje applikation endast de behörigheter den behöver.

Om en autentiseringsuppgift exponeras ska du återkalla eller ersätta den och uppdatera de tjänster som använder den. Ta bort exponerade kopior, utred om någon har använt den utan tillstånd och förhindra att hemligheter dyker upp i framtida loggar. Att ta bort en hemlighet från din kod inaktiverar inte den eller raderar den från gamla Git-commits.

Få en säkerhetsgranskning av PHP utförd av en expert

Boka ett samtal

Hur man prioriterar, implementerar och verifierar PHP säkerhetskorrigeringar

01
Prioritera sårbarheter

Prioritera system som är utsatta för attacker. Väg in CVSS-poängen tillsammans med PHP SAPI, exponering mot internet, befintliga skyddsåtgärder och påverkan på verksamheten. Ouppdaterade mod_php-arbetsbelastningar som är exponerade mot internet kräver omedelbar åtgärd, medan andra SAPI:er fortfarande behöver utvärderas.

02
Installera uppdateringar på ett säkert sätt

Dokumentera berörda applikationer, PHP-arbetspooler och sammanfattningar av containeravbildningar. Testa i staging-miljön och utarbeta en återställningsplan innan distributionen. Applicera patchar på berörda paket eller bygg om bilder, och starta sedan om eller byt ut alla berörda arbetare. WAF-regler och konfigurationsåtgärder kan minska exponeringen för specifika utnyttjandevägar. De åtgärdar inte den sårbara körmiljön.

03
Kontrollera att åtgärderna har genomförts

Kontrollera vilken PHP-version som hanterar liveförfrågningar och verifiera dess patchstatus, inklusive eventuella backports från leverantören. Kontrollera att berörda arbetare har startats om eller bytts ut, kör regressionstester och upprepa den säkerhetskontroll som tidigare misslyckades. Övervaka produktionsmiljön för eventuella fel efter driftsättningen.

04
Undersök om systemet har utsatts för intrång

Genom att installera en patch åtgärdas sårbarheten. Eventuella tidigare intrång måste fortfarande utredas. Granska serverloggar, programkrascher, okända filer och misstänkt nätverksaktivitet. I mod_php kan PHP2Shell köras innan applikationens loggning påbörjas, vilket innebär att rena ramverksloggar inte kan utesluta en attack. Eskalera varningssignaler till incidenthanteringen och bevara bevisen.

05
Upprätthålla säkerheten

Håll koll på nya PHP-sårbarheter och sårbarheter i beroenden, och inför säkerhetskontroller i CI/CD. Basera regelbundna utvärderingar på applikationens exponering och affärsrisker, och gör en ny utvärdering efter större förändringar eller kritiska avslöjanden.

arrow-icon.arrow-icon.
01 Prioritera sårbarheter

Prioritera system som är utsatta för attacker. Väg in CVSS-poängen tillsammans med PHP SAPI, exponering mot internet, befintliga skyddsåtgärder och påverkan på verksamheten. Ouppdaterade mod_php-arbetsbelastningar som är exponerade mot internet kräver omedelbar åtgärd, medan andra SAPI:er fortfarande behöver utvärderas.

arrow-icon.arrow-icon.
02 Installera uppdateringar på ett säkert sätt

Dokumentera berörda applikationer, PHP-arbetspooler och sammanfattningar av containeravbildningar. Testa i staging-miljön och utarbeta en återställningsplan innan distributionen. Applicera patchar på berörda paket eller bygg om bilder, och starta sedan om eller byt ut alla berörda arbetare. WAF-regler och konfigurationsåtgärder kan minska exponeringen för specifika utnyttjandevägar. De åtgärdar inte den sårbara körmiljön.

arrow-icon.arrow-icon.
03 Kontrollera att åtgärderna har genomförts

Kontrollera vilken PHP-version som hanterar liveförfrågningar och verifiera dess patchstatus, inklusive eventuella backports från leverantören. Kontrollera att berörda arbetare har startats om eller bytts ut, kör regressionstester och upprepa den säkerhetskontroll som tidigare misslyckades. Övervaka produktionsmiljön för eventuella fel efter driftsättningen.

arrow-icon.arrow-icon.
04 Undersök om systemet har utsatts för intrång

Genom att installera en patch åtgärdas sårbarheten. Eventuella tidigare intrång måste fortfarande utredas. Granska serverloggar, programkrascher, okända filer och misstänkt nätverksaktivitet. I mod_php kan PHP2Shell köras innan applikationens loggning påbörjas, vilket innebär att rena ramverksloggar inte kan utesluta en attack. Eskalera varningssignaler till incidenthanteringen och bevara bevisen.

arrow-icon.arrow-icon.
05 Upprätthålla säkerheten

Håll koll på nya PHP-sårbarheter och sårbarheter i beroenden, och inför säkerhetskontroller i CI/CD. Basera regelbundna utvärderingar på applikationens exponering och affärsrisker, och gör en ny utvärdering efter större förändringar eller kritiska avslöjanden.

Exempel: en produktionsuppdatering som verkar ha lyckats men som i själva verket inte har det

En Symfony-webbutik kör PHP 8.3 bakom nginx och PHP-FPM. Administratören uppdaterar operativsystemspaketen och kör php -v. Kommandot visar en uppdaterad version, så allt ser bra ut. Men php -v kontrollerar endast den PHP-binärfilen på kommandoraden.

Kundförfrågningar går fortfarande via nginx till PHP-FPM-arbetare som startades före uppdateringen. Bakgrundsjobb körs också i en separat container med ett sårbart PHP-baslager. Paketen kan vara uppdaterade på servern, men dessa arbetsbelastningar kör fortfarande den gamla koden.

PHP build checks for web, workers, and CLI.

För att slutföra korrigeringen måste teamet identifiera alla berörda applikationer och arbetarpooler, starta om FPM-arbetarna och distribuera köcontainern på nytt med en korrigerad bild. Därefter måste de kontrollera att de aktiva PHP-processerna använder korrigerade versioner eller verifierade leverantörsbackports.

Testa utcheckning och filuppladdningar i staging-miljön, kör smoke-tester i produktionsmiljön och upprepa de säkerhetskontroller som tidigare misslyckades. Distributionsloggen bör innehålla den PHP SAPI som hanterar webbtrafiken, verifierade paketversioner eller bildsammanfattningar, bevis på omstart och testning samt ansvarig person.

En godkänd Composer-granskning är inte ett bevis på att PHP2Shell har åtgärdats. Det kommandot kontrollerar beroenden, inte den PHP-tolken som hanterar webbförfrågningar.

Granska PHP-arbetarens användar-ID, skrivbara kataloger, monterade hemligheter, databasbehörigheter och utgående nätverksåtkomst. Dessa avgör om en angripare kan ändra applikationsfiler, läsa inloggningsuppgifter eller nå andra system. Principen om minsta möjliga behörighet och nätverkssegmentering kan begränsa skadan om en arbetare komprometteras, men det är fortfarande nödvändigt att patcha tolken.

php -v visar kommandoradsversionen av PHP, men det går inte att bekräfta vilken tolk som hanterar produktionstrafiken eller om långkörande arbetsprocesser fortfarande använder den sårbara versionen. Med PHP2Shell verifierar vi först den aktiva körmiljön och granskar sedan beroenden och applikationskoden. Vi anser att åtgärdandet är slutfört först efter att vi har bekräftat att den uppdaterade versionen faktiskt hanterar produktionsförfrågningar.
Stanislav Kazanov, Head of GRC and Cybersecurity.
Stanislav Kazanov
Chef för GRC, cybersäkerhet och hållbarhet

Hur Innowise kan hjälpa dig att säkra dina PHP-applikationer

Hos Innowise förenar vi PHP-utveckling och säkerhetsexpertis. Våra över 100 PHP-utvecklare har levererat över 250 projekt, och våra över 50 cybersäkerhetsingenjörer hjälper till att identifiera och åtgärda sårbarheter. Vårt arbete stöds dessutom av certifieringarna ISO/IEC 27001:2022 och ISO 9001:2015.

Vi granskar dina PHP-applikationer för säkerhetsproblem, inklusive sårbara beroenden och föråldrade komponenter. Våra utvecklare sköter nödvändiga korrigeringar och uppgraderingar, medan säkerhetsingenjörerna testar ändringarna innan de släpps. Om du är osäker på var du ska börja kan vårt IT-säkerhetskonsultteam kan utvärdera riskerna och hjälpa till att prioritera arbetet.

ISO 27001 icon.
ISO-27017-2015.
ISO-27018 icon.
ISO 9001 icon.

Våra PHP-projekt

Omdesign och ombyggnad av MedSpa Networks webbplats
Innowise byggde om MedSpa Networks webbplats i WordPress, vilket gav företagets team möjlighet att själva sköta de dagliga innehållsuppdateringarna.
2 månader från projektstart till lansering
3-5 leads per vecka (en ökning från 1 per månad)
Läs fallstudien
Kundrecension
Läs fallstudien
Client review logo. Kundrecension
MedSpa Network website redesign and rebuild.
AI-bot för TBC Banks marknadsföringskampanj
Innowise har utvecklat en tvåspråkig Telegram-bot som skapar AI-selfies med TBC Banks fotbollsstjärna som varumärkesambassadör.
3,000 engagerade användare
2 språk som stöds
Läs fallstudien
Kundrecension
Läs fallstudien
Client review logo. Kundrecension
AI Telegram bot..
Produktstrategi för Bitlendex plattform för bitcoin-utlåning
Innowise genomförde en utredningsfas för Bitlendex och hjälpte kunden att omvandla ett produktkoncept i ett tidigt skede till en validerad affärsmodell och en tydligt definierad MVP.
1 månad under hela utredningsfasen
Läs fallstudien
Läs fallstudien
Defining the product strategy for Bitlendex’s bitcoin lending platform.
Finansiellt rådgivningssystem för Bonnfinanz
Innowise hjälpte Bonnfinanz att utveckla ett webbaserat rådgivnings- och administrationssystem som möjliggör mobilt arbete och direkt interaktion med kunden.
Läs fallstudien
Läs fallstudien
Financial advisory system for Bonnfinanz..
Laddningsplattform för elbilar med flexibel fakturering
Innowise bidrog till att modernisera SMART/LAB:s plattform för e-mobilitet genom att förbättra funktionerna för fakturering, betalning, transaktionshantering och rapportering.
>50% snabbare fakturering och betalningshantering
Läs fallstudien
Läs fallstudien
Laddningsplattform för elfordon med flexibel fakturering.
FinXPs molnbaserade DevOps-transformation
Innowise hjälpte FinXP att modernisera sin infrastruktur för finansiella tjänster genom att migrera äldre PHP-baserade API:er och applikationer till en molnbaserad arkitektur.
11 appar som har flyttats till Azure App Service
100% Infrastruktur som kod
Läs fallstudien
Läs fallstudien
FinXP’s cloud-native DevOps transformation.
Teknisk SEO för e-handelsplattform
Innowise åtgärdade kritiska tekniska SEO- och prestandaproblem på Officine 08:s e-handelsplattform.
<500 ms serverns svarstid
5 månader för att slutföra projektet
Läs fallstudien
Kundrecension
Läs fallstudien
Client review logo. Kundrecension
Teknisk SEO för e-handelsplattform.
Kontinuerlig utveckling av en prenumerationsplattform för parfymer
Innowise hjälpte Scentbird att utöka sin prenumerationsplattform för att möjliggöra nya shoppingupplevelser och internationell tillväxt.
4 många års kontinuerligt stöd
Läs fallstudien
Kundrecension
Läs fallstudien
Client review logo. Kundrecension
Continuous development of a fragrance subscription platform.
01 / 01
Close popup icon

Slutsats

PHP2Shell avslöjade en allvarlig säkerhetsrisk i själva PHP-tolken. Uppdateringar av ramverk och kontroller av beroenden åtgärdar inte sårbarheter på den nivån. Företag måste identifiera varje PHP-körmiljö som hanterar webbförfrågningar, installera säkerhetsuppdateringarna och verifiera att produktionsservrarna kör de uppdaterade versionerna.

PHP-säkerhet kräver också regelbundna kontroller av applikationskod, konfiguration och åtkomstkontroller, särskilt efter avslöjanden av kritiska sårbarheter eller större uppdateringar. Om du behöver hjälp med att bedöma din exponering eller verifiera korrigeringarna, Innowise:s IT-säkerhetskonsult och cybersäkerhetsutvärdering kan stödja det arbetet.

FAQ

Din applikation kan vara utsatt för risk om din server kör en PHP-version som inte har uppdaterats för CVE-2026-109618 och CVE-2026-109619. Kontrollera vilken PHP-version som faktiskt körs och om din webbhotellleverantör har tillämpat korrigeringarna. Apache mod_php har den högsta bekräftade risken, men PHP-FPM behöver också kontrolleras. Eftersom sårbarheterna finns i PHP självt kommer en uppdatering av WordPress eller ett annat ramverk inte att åtgärda dem.

Korrigeringar för PHP2Shell finns tillgängliga i PHP 8.2.35, 8.3.36, 8.4.27 och 8.5.12. Vissa Linux-leverantörer har bakåtportat korrigeringarna till äldre versioner, så kontrollera din leverantörs säkerhetsmeddelande. Se till att dina aktiva PHP-processer använder den uppdaterade versionen. I Windows ska du installera de uppdaterade paketen från den 26 oktober som slutar på -1, vilka även åtgärdar en separat sårbarhet i Brotli.

Om du inte kan uppdatera PHP omedelbart bör du, där det är möjligt, begränsa allmänhetens åtkomst till de berörda applikationerna. För webbplatser som måste förbli online kan din serveradministratör vidta tillfälliga åtgärder enligt säkerhetsmeddelandet för PHP, till exempel att begränsa storleken på förfrågningar eller inaktivera uppladdningsförloppet för sessioner. Testa dessa ändringar för att säkerställa att webbplatsen fortfarande fungerar. De minskar endast risken, så det är fortfarande brådskande att installera en uppdaterad PHP-version.

Nej. Att uppdatera PHP åtgärdar sårbarheter i PHP-körmiljön, men det åtgärdar inte säkerhetsproblem i din applikationskod, föråldrade plugins eller serverkonfigurationen. Du måste kontrollera och åtgärda dessa separat.

Jag rekommenderar att man kontrollerar PHP-applikationer för kända sårbarheter minst en gång i månaden, med mer frekventa kontroller för system med hög risk. Håll kontinuerligt koll på PHP-säkerhetsmeddelanden och beroenden, och planera in mer grundliga granskningar utifrån din applikations exponering och affärsrisk. Ytterligare tester är viktiga efter större uppdateringar eller när kritiska sårbarheter har offentliggjorts.

Kontrollera PHP-säkerhetsmeddelanden och bulletiner från din webbhotellsleverantör eller operativsystemleverantör för kända sårbarheter. Använd composer audit --locked för att kontrollera beroenden, utför statisk analys och kodgranskning för att upptäcka problem på applikationsnivå, och OWASP ZAP för att testa din webbapplikation med behörighet. För att verifiera säkerhetsuppdateringar, kontrollera vilken PHP-version som körs i produktion och eventuella korrigeringar som har backporterats av din leverantör.

Ja. Uppdateringar kan orsaka kompatibilitetsproblem med äldre kod eller tillägg. Testa dem i en testmiljö innan du uppdaterar din live-applikation, och se till att ha en återställningsplan redo ifall något slutar fungera.

Korskontrollera loggar från omvänd proxy, Apache/nginx, PHP-FPM och EDR/värd. Leta efter krascher hos arbetare, misstänkta filer eller processer, oväntad utgående trafik och tecken på att inloggningsuppgifter har läckt ut. Applikationsloggar kan missa PHP-utnyttjanden under körning som inträffar innan ramverket börjar logga. Om du upptäcker misstänkt aktivitet, inled incidenthantering och bevara forensiska bevis.

Visa mer Visa mindre

Innehållsförteckning

Ta reda på vilka PHP-arbetsbelastningar som behöver en säkerhetsuppdatering först

Utvärdera min PHP-exponering

    Kontakta oss

    Boka ett samtal eller fyll i formuläret nedan så återkommer vi till dig när vi har behandlat din förfrågan.

    Skicka ett röstmeddelande till oss
    Bifoga dokument
    Ladda upp filen

    Du kan bifoga 1 fil på upp till 2 MB. Giltiga filformat: pdf, jpg, jpeg, png.

    Genom att klicka på Skicka samtycker du till att Innowise behandlar dina personuppgifter enligt vår integritetspolicy för att förse dig med relevant information. Genom att lämna ditt telefonnummer samtycker du till att vi kan kontakta dig via röstsamtal, SMS och meddelandeappar. Avgifter för samtal, SMS och datatrafik kan tillkomma.

    Du kan också skicka din förfrågan till oss

    på contact@innowise.com
    Vad händer härnäst?
    1

    När vi har tagit emot och behandlat din förfrågan återkommer vi till dig för att diskutera era projektbehov och underteckna ett sekretessavtal (NDA).

    2

    Efter att ha undersökt dina önskemål, behov och förväntningar kommer vårt team att ta fram ett projektförslag med arbetsomfattning, teamstorlek, tids- och kostnadsberäkningar.

    3

    Vi ordnar ett möte med dig för att diskutera erbjudandet och fastställa detaljerna.

    4

    Slutligen signerar vi avtalet och påbörjar arbetet med ert projekt omgående.

    Relaterat innehåll

    Blogg
    Generative AI trends in 2026: key technologies and future outlook.
    Trender inom generativ AI år 2026: nyckelteknologier och framtidsutsikter
    Upptäck de viktigaste trenderna inom generativ AI år 2026. Lär dig hur olika branscher använder GenAI, vilka risker som finns och vad som väntar härnäst.
    Michael Labutin
    5 november 2026
    Blogg
    AI discoverability: how to get your brand found, cited, and recommended by AI.
    Sökbarhet för AI: hur du ser till att ditt varumärke hittas, citeras och rekommenderas av AI
    Ditt varumärke kan ha en bra placering på Google och ändå vara osynligt för ChatGPT. Låt oss se vad AI-synlighet kan göra åt saken.
    Yuliya Pantsiuk
    4 november 2026
    Blogg
    AI in supply chain and logistics: use cases, benefits, and implementation.
    AI inom leveranskedjan och logistiken: användningsfall, fördelar och implementering
    AI tar över logistikbranschen, och dina konkurrenter är medvetna om det. Ta reda på var det fungerar, vilka besparingar det ger och hur du kan komma ikapp.
    Philip Tikhanovich
    4 november 2026
    Blogg
    AI in social media: use cases, benefits, and trends.
    AI i sociala medier: användningsfall, fördelar och trender
    Nyhetsflöden, filter, översättning, moderering: AI finns överallt på sociala medier. Låt oss ta en titt bakom kulisserna.
    Philip Tikhanovich
    30 oktober 2026
    Blogg
    AI in CRM: use cases, benefits, and implementation.
    AI inom CRM: användningsfall, fördelar och implementering
    Vilka AI-CRM-funktioner lever upp till förväntningarna? Vi går igenom användningsfall, plattformar, risker och avkastning på investeringen.
    Raman Karabach
    14 oktober 2026
    Blogg
    AI chatbots in healthcare: use cases, benefits, and implementation.
    AI-chattbotar inom hälso- och sjukvården: användningsfall, fördelar och implementering
    En expertguide till AI-chattbotar inom hälso- och sjukvården: konkreta användningsexempel, fördelar och viktig integration.
    Roman Sen
    24 september 2026
    Blogg
    AI in medical imaging: applications, benefits, and implementation.
    AI inom medicinsk bilddiagnostik: tillämpningar, fördelar och implementering
    En klarsynt betraktelse av hur AI används inom medicinsk bilddiagnostik idag.
    Aleh Yafimau
    1 september 2026
    Blogg
    LLM-as-a-judge: how we evaluate AI systems at scale.
    LLM som domare: hur vi utvärderar AI-system i stor skala
    Utvärdera LLM-resultat med tydligare bedömningskriterier, tydligare poängsättning och färre blinda fläckar.
    Philip Tikhanovich
    22 juli 2026
    Blogg
    Best 10 data modernization companies in 2026.
    De 10 bästa företagen inom datamodernisering 2026
    Jämför de bästa företagen inom datamodernisering och välj en partner för arbete med äldre system, molnlösningar och AI-förberedda data.
    Philip Tikhanovich
    16 juli 2026
    Blogg
    Microsoft Dynamics 365 for financial services: a complete guide.
    Microsoft Dynamics 365 för finanssektorn: en komplett guide
    Banker älskar system. Team avskyr dåliga system. Här kan Dynamics 365 vara till hjälp.
    Siarhei Sukhadolski
    13 juli 2026
    Blogg
    Best 9 ERP consulting companies in 2026.
    De 9 bästa ERP-konsultföretagen 2026
    Jämför de 9 bästa ERP-konsultföretagen år 2026. Ta del av deras expertis och branschinriktning och få tips på hur du väljer rätt partner för just dig.
    Kiryl Drabysheuski
    10 juli 2026
    Blogg
    Enterprise AI adoption trends 2026.
    Trender för införandet av AI i företag 2026
    De mest betydelsefulla AI-trenderna 2026 och hur de förändrar företagen för alltid.
    Philip Tikhanovich
    7 juli 2026

    Fler tjänster vi täcker

    Verksamhet
    AIOps BPA Hanterade IT-tjänster MLOps konsultverksamhet RPA
    Visa mer
    QA
    Testautomatisering QA för e-handelsappar ERP-testning Penetrationstestning QA-rådgivning QA-ingenjörer Säkerhetstestning Testning Penetrationstestning av webbappar
    Visa mer

    arrow