Hi Cedric, the vulnerability affects the Shibboleth SAML SP software, not the IDP software included in your Gluu Server. If your organization is using the Shibboleth SP software, or any of your application partners are using the Shibboleth SP software, it should be upgraded immediately and the affected processes should be restarted (e.g. shibd, Apache, etc.). The [Shibboleth advisory](https://shibboleth.net/community/advisories/secadv_20180227.txt) has links for patched versions of the SP software. BTW, if you should be associated with your organizations support account, you should request your colleage, Stephane, update your privileges so you can open private tickets with us. Thanks, Will

In case you are using the Shib SP software anywhere... Add the following to the shibboleth2.xml: ``` <CredentialResolver type="File" key="sp-key.pem" certificate="sp-cert.pem"></CredentialResolver> <ApplicationDefaults id="default" policyId="default" entityID="https://sp-example.com" REMOTE_USER="eppn persistent-id targeted-id" signing="true" encryption="true" > ``` Specifically: > signing="true" encryption="true" Then make sure you do some testing. In Gluu, the relying party `encryptAssertions` is always set to 'never' because there are lot of SPs out there which can't work with encrypted Assertion. You can update that in your SAML TR Relying Party configuration, as shown [in the screenshot in the docs](https://gluu.org/docs/ce/3.1.2/admin-guide/saml/#relying-party-configuration). And then just to highlight one note in the announcement from Shibboleth: > " No actual attacks of this nature are known, so deployers should prioritize patching systems that expect to handle unencrypted SAML assertions." Hope that helps. I'm going to close this ticket out now. Feel free to comment if you need additional assistance. Thanks, Will

Thanks!