Hej,
På grund av de säkerhetsbrister som beskrivs i CVE-2026-109618 och CVE-2026-109619 har vi som försiktighetsåtgärd stängt av ett antal tjänster. De är avstängda tills PHP (och därefter Debian) har släppt patchar och vi har byggt om tjänsten.
Vi har inte sett några indikationer på intrång. Avstängningen är enbart en förebyggande åtgärd.
Tjänster som berörs
* Metadata-administration: Metadata kan inte uppdateras eller administreras under avstängningen.
* Testverktyg (release-check): Det går inte att verifiera attributsläpp med testverktyget.
* Felsidor (errorurl): Felsidor som er IdP hänvisar användare till via errorurl är inte tillgängliga.
Vad innebär det för dig?
* Inga ändringar i er metadata kan göras via administrationsgränssnittet.
* Användare som får ett fel vid inloggning kan mötas av en felsida som inte fungerar. Överväg att informera supporten hos er.
* Inloggning via SAML fungerar i övrigt som vanligt.
Vi återkommer så fort tjänsterna är återställda. Behöver ni göra en akut metadataändring under tiden är ni välkomna att kontakta oss på operations@swamid. <mailto:operations@swamid.e>se
Vi beklagar det inträffade och de olägenheter det medför.
--
Swamid Operations via jocar
Hej,
Under den senaste tiden har vi fått in två spammare på saml-adminslistan. Vid varje tillfälle har vi så snabbt som möjligt blockerat dessa användare. Detta är ett nytt beteende så jag har ändrat reglerna för att bli medlem på listan. Numera krävs att vi i swamidoperations godkänner nya medlemmar. Det gör tyvärr det lite mer trögt när man vill gå med men det minskar risken kraftigt för spammare. Redan sedan tidigare kräver vi att man måste vara medlem för att skicka till listan.
Pål
Uppdateringen av Shibboleth som kom förra veckan var ett par viktiga säkerhetsuppdatering och det är rekommenderat att uppdatera så snart som möjligt.
Pål
From: announce <announce-bounces(a)shibboleth.net> On Behalf Of Scott Cantor via announce
Sent: Wednesday, May 13, 2026 10:09 PM
To: announce(a)shibboleth.net
Cc: Scott Cantor <scott(a)restingparrotsoftware.com>
Subject: Shibboleth Identity Provider Security Advisory [13 May 2026]
OpenPGP meddelande
Vänta medan meddelandet verifieras...
Shibboleth Identity Provider Security Advisory [13 May 2026]
The Shibboleth Identity Provider has, for some time, included a
library known as "JavaMail", more recently "JakartaMail", used
by the Logback logging library to support sending log output
via SMTP mail.
A vulnerability in this library, while not deemed critical in
its own right, has led us to make the unusual decision to remove
this library from the IdP distribution due to the risk of a more
serious vulnerability in the future.
The Jakarta Mail vulnerability was recorded as CVE-2025-7962.
Injection vulnerability in SMTP Library included with IdP
=========================================================
The Shibboleth Identity Provider dating back to at least V3.0
includes a library not used by the IdP itself but present to
support an optional Logback feature, an SMTP Appender [1]
that supports log output via SMTP.
It is typically used in conjunction with a filter to limit
the use of the feature to specific log messages of particular
import.
The version of the library shipped with recent versions of the
IdP includes a vulnerability, CVE-2025-7962, that allowed
for SMTP injection based on specially crafted log messages.
The most likely vector for exploit would involve logging
that can be influenced by user input.
Because we believe this feature is very little used and because
we are more concerned about the possibility of future exploits
that could be more serious, we have taken the step of removing
this library from a patch release of the IdP and will not be
replacing it with a fixed version.
Recommendations
===============
Update to V5.2.2 (or later) of the Identity Provider software.
If making use of the Logback SMTP Appender feature, inject a fixed
version of the Jakarta Mail library via the IdP's "edit-webapp"
customization mechanism and rebuild the IdP.
See [2] for the project's home page. The self-contained version
of the library that corrects the specific CVE reported is V2.0.2;
note that this is true despite the official CVE claiming otherwise.
Newer versions (V2.1.x) have a separate implementation jar along
with the original API jar. Refer to their documentation for
specifics.
Notably, use this feature at your own risk. We as a project do
not consider it wise to include an SMTP implementation on the
class path given the risk of a more serious issue causing
exfiltration vulnerabilities.
Credits
=======
Philip Brusten
[1] https://logback.qos.ch/manual/appenders.html#SMTPAppender
[2] https://jakartaee.github.io/mail-api/
URL for this Security Advisory:
https://shibboleth.net/community/advisories/secadv_20260513b.txt
Hej.
Vi vill stämma av en sak gällande hur vår IdP hanterar authnContextClassRef, då vi ibland kommer skicka värdet urn:oasis:names:tc:SAML:2.0:ac:classes:Unspecified till tjänster i federationen.
Vår inloggning kommer bygga på Microsoft Entra ID där användare ofta loggar in helt lösenordslöst. För oss känns det mest korrekt att skicka detta värde som det är, istället för att maskera inloggningen och skriva om den till urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport, vilket inte är sant.
Entra ID skickar även urn:oasis:names:tc:SAML:2.0:ac:classes:Password. Vårt mål är att skriva om det till PasswordProtectedTransport, men det har vi inte lyckats med ännu. Så det kan också vara ett värde vi kommer skicka.
Vi utgår från att detta kommer fungera i federationerna, men säg till om ni ser några tekniska problem med det eller om ni har några invändningar.
Med vänlig hälsning,
Eric Johansson
Karolinska Institutet
När du skickar e-post till Karolinska Institutet (KI) innebär detta att KI kommer att behandla dina personuppgifter. Här finns information om hur KI behandlar personuppgifter<https://ki.se/om-ki/integritetsskyddspolicy>.
Sending email to Karolinska Institutet (KI) will result in KI processing your personal data. You can read more about KI’s processing of personal data here<https://staff.ki.se/data-protection-policy>.
FYI
// Björn M.
Begin forwarded message:
From: Philip Smart via announce <announce(a)shibboleth.net>
Subject: WebAuthn plugin V1.4.3 now available
Date: 12 October 2026 at 21:07:52 GMT+2
To: "announce(a)shibboleth.net" <announce(a)shibboleth.net>
Cc: Philip Smart <Philip.Smart(a)jisc.ac.uk>
Reply-To: users(a)shibboleth.net
The Shibboleth Project has released version 1.4.3 of the WebAuthn Authentication Plugin.
This patch release primarily updates the Yubico WebAuthn libraries to version 2.10.1, which fixes a bug in FIDO Metadata processing and improves trust root handling.
For full details, please refer to the release notes [1].
— Phil Smart, on behalf of the team
[1] https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3394928781/We…
Jisc is a registered charity (in England and Wales under charity number 1149740; in Scotland under charity number SC053607) and a company limited by guarantee registered in England under company number 05747339, VAT number GB 197 0632 86. Jisc's registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800.
Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 02881024, VAT number GB 197 0632 86. The registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800.
For more details on how Jisc handles your data see our privacy notice here: https://www.jisc.ac.uk/website/privacy-notice
--
To unsubscribe from this list send an email to announce-unsubscribe(a)shibboleth.net
Hej.
I samband med en översyn av våra processer kring samordningsnummer så noterar vi en sak som väcker frågor. Vår implementation gällande generering av schacDateOfBirth baseras på informationen på SWAMID:s Wiki https://wiki.sunet.se/spaces/SWAMID/pages/69042390/Svenska+personnummer+nor… samt https://wiki.sunet.se/spaces/SWAMID/pages/69042384/Example+of+a+standard+at…. Där förespråkas (i princip) att direkt bara plocka de första 8 tecknen från norEduPersonNIN, vilket innehåller personnummer eller samordningsnummer, dock ej interimspersonnummer. Vad som blir fel här är i så fall att schacDateOfBirth innehåller ett värde som inte är ett datum i de fall vi använder norEduPersonNIN som källa. Taget från specen på https://wiki.refeds.org/display/STAN/SCHAC+Releases?preview=/44957731/12890… så skall värdet vara av formatet "Numeric value YYYYMMDD, using 4 digits for year, 2 digits for month and 2digits for day as described in RFC 3339 'Date and Time on the Internet:Timestamps' as reference using the 'full-date' format from paragraph 5.6 but without the dashes.".
Nu vill jag justera vår implementation så att vi justerar bort de extra 60 dagarna från samordningsnummer, detta så att vi följer standarden så att vi för en person släpper samma schacDateOfBirth som t.ex. en annan tjänst gör. Rätt eller fel?
Är det någon som ser problem/risker med att byta implementationen? Vi kommer ju i så fall släppa ändrade schacDateOfBirth för personer. Är det någon annan som tidigare noterat detta och som vill dela med sig av erfarenheter av en justering? Har vi inom SWAMID ett undantag i hanteringen av detta fält, som gör att vi oss emellan förväntas kunna skicka samordningsvärden istället? Problemet jag upplever blir när vi autentiserar mot tjänster som förväntar sig "korrekta" datum.
Med vänlig hälsning
/Johan
_________________________________________
Johan Hjortskull
Systemarkitekt
Linnéuniversitetet
IT-avdelningen
391 82 Kalmar / 351 95 Växjö
Lnu.se
Vi sätter kunskap i rörelse för en hållbar samhällsutveckling. Linnéuniversitetet - ett modernt, internationellt universitet i Småland.
Vi behandlar personuppgifter enligt reglerna i Dataskyddsförordningen, se Lnu.se/personuppgifter<https://lnu.se/mot-linneuniversitetet/kontakta-och-besoka/personuppgifter/>.
The real-time monitoring of gas consumption across residential, commercial, and industrial applications is being enabled by smart gas meters that provide accurate data, remote reading, and enhanced customer engagement. Analysis presented by Market Research Future reveals that as utilities seek to improve efficiency, smart gas meters continue to gain adoption.
Report Key Statistics
Market Research Future's analysis indicates that the AMI Gas Meter Market was valued at USD 4,129.28 million in 2024, with projections to reach USD 8,420.28 million by 2035 at a compound annual growth rate of 6.69%.
Conclusion
The AMI Gas Meter Market continues to evolve with advancing technology and changing customer requirements. While challenges related to privacy, data security, and acceptance persist, ongoing innovation ensures that meters will continue to improve. The evolution toward behavioral analytics and demand response will define the competitive landscape through 2035.
Read More: https://www.marketresearchfuture.com/reports/ami-gas-meter-market-33675
The real-time monitoring of gas consumption across residential, commercial, and industrial applications is being enabled by smart gas meters that provide accurate data, remote reading, and enhanced customer engagement. Analysis presented by Market Research Future reveals that as utilities seek to improve efficiency, smart gas meters continue to gain adoption.
Report Key Statistics
Market Research Future's analysis indicates that the AMI Gas Meter Market was valued at USD 4,129.28 million in 2024, with projections to reach USD 8,420.28 million by 2035 at a compound annual growth rate of 6.69%.
Smart Meters dominate the technology segment. Residential Consumers represent the fastest-growing end-use segment.
Industry Trends: Customer Engagement and Energy Efficiency
The most significant trend in smart gas meters is enhanced customer engagement.
Energy efficiency insights are driving adoption.
Real-time data enables behavioral changes.
Challenges: Privacy and Data Security
Privacy considerations affect deployment.
Data security requirements are stringent.
Consumer acceptance varies by region.
Future Outlook: Behavioral Analytics and Demand Response
The future of smart gas meters lies in behavioral analytics.
Demand response integration will enable grid support.
Advanced features will improve customer value.
Expert Discussion: Meter Selection
Industry observations from Market Research Future highlight the importance of meter selection.
Communication capabilities affect functionality.
Data management affects value.
Conclusion
The AMI Gas Meter Market continues to evolve with advancing technology and changing customer requirements. While challenges related to privacy, data security, and acceptance persist, ongoing innovation ensures that meters will continue to improve. The evolution toward behavioral analytics and demand response will define the competitive landscape through 2035.
Read More: https://www.marketresearchfuture.com/reports/ami-gas-meter-market-33675
Byte av användaridentifierare i Ladok för studenter
I samband med leverans av 3.4.0 onsdagen den 7 oktober byter Ladok användaridentifierare i Ladok för studenter från ePPN till subject-id.
Vad innebär förändringen?
Alla lärosäten (och eduID) skickar redan idag giltiga subject-id för sina studenter till Ladok. Det innebär att inga anpassningar behöver göras i lärosätenas inloggningstjänster (SWAMID-IdP) inför bytet.
Idag används scope-delen av ePPN i Ladok för studenter för att avgöra vilket lärosäte som ska vara förvalt vid inloggning. Efter bytet kommer Ladok i stället att använda scope-delen av subject-id för samma ändamål. Eftersom Ladok för studenter endast använder scope för att identifiera lärosätet förväntas det heller inte bli någon påverkan på lärosäten eller studenter. Några lärosäten har annat scope i subject-id jämfört med ePPN. För dessa lärosäten finns redan båda dessa scopes i Ladok, så ingen påverkan förväntas på grund av detta.
Det förekommer ibland inloggningar i Ladok för studenter från diverse lärosäten där subject-id saknas eller har ogiltig syntax (exempelvis med en punkt (.) eller ett understreck (_) i användardelen). Det har hittills handlat om felkonfigurering i IdP:n eller asynkron generering av subject-id i IdP:n. Från och med onsdagen kommer studenter i de fallen att få ett felmeddelande och inte kunna logga in. Var förberedd på eventuella supportärenden rörande detta.
Varför byter vi till subject-id?
Bytet till subject-id görs för att göra det möjligt för studenter att koppla ytterligare inloggningsmetoder till Ladok, exempelvis inloggning från ett utländskt lärosäte eller via eduID, utöver alternativ inloggning via eIDAS och Freja för utländska personer.
Ladok för personal
Ladok planerar även för byte till subject-id för personal. Detta har större påverkan då ePPN (och snart i stället subject-id) används för att identifiera användare i Ladok. Vi återkommer med mer information när det närmar sig byte även i Ladok för personal.
/Fredrik
Fredrik Domeij
----------------------------------
Ladok Operations
IT-stöd och systemutveckling (ITS)
Umeå universitet
901 87 Umeå
----------------------------------
Telefon: +46 (0)90 786 65 43
Mobil: +46 (0)70 303 78 36
----------------------------------
fredrik.domeij(a)umu.se<mailto:fredrik.domeij@umu.se>
www.umu.se/it-stod-och-systemutveckling<http://www.umu.se/it-stod-och-systemutveckling>
