Lector de Feeds

MGASA-2026-0458 - Updated php package fixes security vulnerabilities

Mageia Security - 28 Septiembre, 2026 - 18:04
Publication date: 28 Sep 2026
Type: security
Affected Mageia releases : 9
CVE: CVE-2026-91768 , CVE-2025-1218 , CVE-2026-91769 , CVE-2026-91767 , CVE-2026-6103 , CVE-2026-91765 , CVE-2025-14181 , CVE-2026-92842 , CVE-2026-91766 , CVE-2026-93682 Description
FILTER_SANITIZE_ENCODED does not encode 0xFF IPv6 ACL bypass in FastCGI listen.allowed_clients due to partial address comparison Various packet overreads in mysqlnd wire protocol TLS hostname verification falls back to CN after SAN mismatch Heap buffer overflow in php_openssl_matches_wildcard_name() on crafted server certificate wildcard CN Integer overflow in phar_tar_number() allowing TAR archive entry injection Unbounded recursion in server-side cleanup_xml_node() Integer overflow to buffer overflow in SOAP HTTP parsing) Out-of-bounds read in convert.* stream filters when line-break-chars contains NUL ross-origin credential leak in HTTP stream wrapper redirects Out-of-bounds read in the HTTP stream wrapper when following a redirect with an empty Location header References
SRPMS 9/core
  • php-8.2.34-1.mga9

Pociones en Mageia. 05 – De como Mageia está entre las mejores distros “user-friendly” aunque muchos lo desconocen.

Blog de Mageia-ES - 28 Septiembre, 2026 - 14:03

Esta semana, hemos estado cocinando una poción con algunos ingredientes que nos aporta nuestro gran equipo de desarrolladores y empaquetadores. La gestión y empaquetado de las aplicaciones en Mageia frente a otros competidores hace muy fácil la gestión del sistema y el uso del software para nuestros usuarios. La implementación de las herramientas gráficas como el Centro de Control de Mageia forman una parte importante del sistema, pero lo que realmente se desconoce, es cómo se empaquetan algunas aplicaciones con respecto a otros sistemas, cómo se valora la adhesión de plugins y extras de software para las aplicaciones y cómo se gestionan las dependencias de todo durante el empaquetado. Empecemos!

Principios de concepto

Mageia ha heredado y perfeccionado la filosofía de empaquetado de Mandriva/Mandrake, nuestro objetivo está centrado en entregar las aplicaciones “listas para usar”, sin escatimar en funcionalidades opcionales o complementos. Otras distribuciones tienden a empaquetar las aplicaciones en su versión más ligera dejando aparte los plugins o complementos, esto obliga al usuario a buscar paquetes extra. En Mageia incluimos en muchos casos, plugins, integraciones y soporte multimedia directamente en la aplicación o bajo un único metapaquete.

Mageia destaca por una filosofía de empaquetado integrada: en lugar de fragmentar un programa en múltiples subpaquetes o aplicar recortes de licencias estrictos en el repositorio principal, los mantenedores de Mageia compilan el software con el mayor número de extensiones, filtros y soporte de hardware habilitados de serie, siempre que estos aporten un plus de funcionalidad a la aplicación y sea aprobados por el equipo de empaquetado.

Nuestro instalador

Actualmente en Mageia 10 disponemos de URPMI (User RPM Installer) que es nuestro gestor de paquetes por defecto, y la columna vertebral tanto gráfica como por terminal de instalación de aplicaciones, aunque también se incluye soporte nativo para DNF (ahora DNF5).

Urpmi tiene algunas ventajas frente a sus competidores como por ejemplo:

  • Utiliza archivos de síntesis muy ligeros que contienen únicamente los datos indispensables para resolver dependencias, permitiendo consultar o refrescar repositorios de forma casi instantánea, incluso en conexiones lentas.
  • No necesita almacenar localmente la descripción completa e información de cada paquete si no se requiera, ahorrando espacio en disco en los índices.
  • Una de sus mayores ventajas no es solo la línea de comandos, sino que el gestor de paquetes gráfico “rpmdrake”, comparte el mismo motor. En otros gestores, las herramientas gráficas actúan como wrappers independientes que a veces entran en conflicto o no reflejan los mismos estados de paquetes huérfanos.
  • Urpmi lleva décadas perfeccionando su algoritmo de detección de paquetes huérfanos que quedan tras desinstalar una aplicación, adaptándose a la estructura de paquetes RPM de Mageia, esto evita desinstalar librerías críticas del sistema por error durante la limpieza.

En Mageia también se habilitó DNF por algunas características modernas:

  • Historial de transacciones.
  • Módulos y AppStream. Mejor integración con tiendas de software modernas.
  • Soporte upstream activo. Es mantenido directamente por el proyecto rpm.org.

Algunos comandos de urpmi en terminal:

  • urpme: para eliminar paquetes.
  • urpmq: para consultar paquetes.
  • urpmf: para buscar qué paquete contiene determinados archivos o capacidades.
  • urpmi: para instalación y actualización.


Un breve esquema

En Mageia, a través de nuestras secciones de repositorios, se empaquetan versiones de programas compiladas desde el primer día con soporte habilitado para por ejemplo, todos los módulos de red, protocolos de streaming y aceleración de vídeo por hardware, así como múltiples formatos de imagen propietarios o raros que otras distribuciones mueven a repositorios secundarios o directamente eliminan. Se prioriza la comodidad del usuario final sobre la “pureza” estricta del empaquetado, siempre y cuando un complemento haga más útil a la aplicación empaquetada, esto se debe en gran parte a los repositorios oficiales “Tainted” dedicados a software con patentes o restricciones legales en ciertos países, que permiten empaquetar aplicaciones en su versión completa sin restringir funciones.

En Mageia se mantienen, infraestructura de construcción, dependencias, políticas y controles para que los paquetes formen un sistema coherente.

Un ejemplo claro de esto es el paquete “gimp-plugin-astronomy” que permanece disponible para instalar hasta el fin de soporte de Mageia 9, aunque ha dejado de ser mantenido por sus creadores, en Mageia se ha mantenido para nuestros usuarios hasta el lanzamiento de Gimp 3.0 con el cual ya deja de ser compatible por el paso a Python 3.

Algunos otros ejemplos:

  • Libreoffice. En otras distribuciones se empaqueta en componentes divididos y se omiten por ejemplo temas de iconos o integración con bases de datos o entornos de escritorio.
  • Inkscape. En Mageia incluye un mapa de dependencias que activa por defecto todas las extensiones de renderizado matemático, procesamiento de mapas de bits e importación/exportación de archivos CAD sin tener que buscar otras librerías python.
  • Audacity, Vlc, Kodi. A través de los distintos repositorios, se empaquetan con soporte habilitado para características que no aparecen en otras distribuciones.
  • Pidgin. Ya hablamos de esta aplicación en otra poción. El empaquetado de Mageia es muy completo con muchos plugins y protocolos de mensajería que no se encuentran en otras distribuciones.


Visión de empaquetado en Mageia

Detrás del empaquetado, existen unas políticas definidas y procesos de revisión con los que intentamos que el software encaje en el sistema, en lugar de distribuir los paquetes como los publican los desarrolladores.

Algunas funciones destacadas de nuestro empaquetado:

  • Python. Convenciones claras, pyproject, noarch, documentación y dependencias gestionadas por RPM:
  • Java. Evitamos dependencias JAR duplicadas y mantenemos separación de componentes.
  • Firefox. Paquete principal y traducciones independientes. Se instala el idioma requerido en base al idioma del sistema.
  • Libreoffice. Instalación de toda la suite y el idioma requerido en base al idioma del sistema, en un solo metapaquete, o instalación por separado de aplicativos.
  • Bibliotecas. Separación de runtime, desarrollo y dependencias.
  • Aplicaciones KDE/Qt. Políticas específicas para nombres, bibliotecas y componentes.
  • Licencias. Disponemos de separación de licencias mediante repositorios mantenidos “Core/Nonfree/Tainted/.
  • Actualizaciones validadas por el equipo de QA antes de llegar a estable.


¿Qué aporta todo esto al usuario?

La mayoría de estas decisiones no aparecen en una captura de pantalla. No hacen que Plasma tenga mejores animaciones ni que Firefox abra más rápido por sí mismas.

Su valor aparece en situaciones más cotidianas:

  • Instalar una aplicación y obtener automáticamente sus dependencias correctas.
  • Eliminarla sin dejar archivos desperdigados.
  • Actualizar una biblioteca sin tener varias copias incompatibles.
  • Instalar únicamente los idiomas que necesitamos.
  • Instalar documentación sólo cuando nos interesa.
  • Disponer de paquetes de desarrollo separados.
  • Mantener una base de software coherente.
  • Recibir actualizaciones que han pasado por un proceso de validación.

Es decir, nuestros usuarios no tiene que pensar constantemente en el empaquetado. Si el trabajo está bien hecho, simplemente funciona.

Conclusiones

El principal mérito de nuestro empaquetado, está en como se intenta desde todos los equipos, encajar cada programa dentro del conjunto.

Las políticas de empaquetado, la separación de componentes, el tratamiento de las dependencias, el cuidado con las bibliotecas incluidas por terceros, la gestión de licencias y el proceso de control de calidad, forman un sistema integrado y coherente.

El trabajo de nuestros equipos de empaquetado, desarrollo y control de calidad, aunque no es visible para nuestros usuarios o el público general, es una de las partes más importantes de lo que hace que nuestra distribución sea realmente una distribución Linux estable y confiable. Existe una cantidad de trabajo de ingeniería dedicado a que todo encaje para llegar al resultado final.

Categorías: Blogs Oficiales

Potions in Mageia. 05 – How Mageia ranks amongst the best ‘user-friendly’ distros, even though many people aren’t aware of it.

Blog de Mageia (English) - 28 Septiembre, 2026 - 14:00

This week, we’ve been concocting a potion using a few ingredients provided by our brilliant team of developers and packagers. The way applications are managed and packaged in Mageia, compared to other competitors, makes system management and software usage very straightforward for our users. The implementation of graphical tools such as the Mageia Control Centre forms an important part of the system, but what is not widely known is how certain applications are packaged compared to other systems, how the inclusion of plugins and software extras for applications is handled, and how dependencies are managed throughout the packaging process. Let’s get started!

Conceptual Principles

Mageia has inherited and refined the Mandriva/Mandrake packaging philosophy; our aim is to deliver ‘ready-to-use’ applications, without skimping on optional features or add-ons. Other distributions tend to package applications in their lightest version, leaving out plugins or add-ons, which forces the user to search for extra packages. In Mageia, we often include plugins, integrations and multimedia support directly within the application or under a single metapackage.

Mageia is characterised by an integrated packaging philosophy: rather than splitting a programme into multiple sub-packages or applying strict licence restrictions in the main repository, Mageia’s maintainers compile the software with as many extensions, filters and hardware support features enabled by default as possible, provided these add extra functionality to the application and are approved by the packaging team.

Our installer

In Mageia 10, we currently have URPMI (User RPM Installer), which is our default package manager and the backbone of both the graphical and terminal-based application installation processes, although native support for DNF (now DNF5) is also included.

URPMI has a number of advantages over its competitors, such as:

  • It uses very lightweight summary files containing only the data essential for resolving dependencies, allowing repositories to be queried or refreshed almost instantly, even on slow connections.
  • It does not need to store the full description and information for each package locally unless required, saving disk space in the indexes.
  • One of its greatest advantages is not just the command line, but the fact that the graphical package manager ‘rpmdrake’ shares the same engine. In other managers, the graphical tools act as independent wrappers that sometimes conflict or do not reflect the same statuses of orphaned packages.
  • Urpmi has spent decades refining its algorithm for detecting orphaned packages left behind after uninstalling an application, adapting it to Mageia’s RPM package structure; this prevents critical system libraries from being uninstalled by mistake during the clean-up process.

DNF has also been enabled in Mageia due to a number of modern features:

  • Transaction history.
  • Modules and AppStream. Better integration with modern software repositories.
  • Active upstream support. It is maintained directly by the rpm.org project.

Some urpmi commands in the terminal:

  • urpme: to remove packages.
  • urpmq: to list packages.
  • urpmf: to search for packages containing specific files or capabilities.
  • urpmi: for installation and updates.


A brief diagram

At Mageia, through our repository sections, we package versions of programmes that are compiled from day one with support enabled for, for example, all networking modules, streaming protocols and hardware-accelerated video, as well as numerous proprietary or obscure image formats that other distributions move to secondary repositories or remove altogether. End-user convenience is prioritised over strict ‘purity’ in packaging; provided that an add-on makes the packaged application more useful, this is largely due to the official ‘Tainted’ repositories dedicated to software subject to patents or legal restrictions in certain countries, which allow applications to be packaged in their full version without restricting functionality.

Mageia maintains the build infrastructure, dependencies, policies and controls to ensure that the packages form a coherent system.

A clear example of this is the “gimp-plugin-astronomy” package, which remains available for installation until the end of support for Mageia 9. Although it is no longer maintained by its creators, Mageia has continued to provide it for our users until the release of GIMP 3.0, with which it is no longer compatible due to the switch to Python 3.

Some other examples:

  • LibreOffice. In other distributions, it is packaged as separate components, and features such as icon themes, database integration or desktop environments are omitted.
  • Inkscape. In Mageia, it includes a dependency map that enables, by default, all extensions for mathematical rendering, bitmap processing and the import/export of CAD files, without the need to search for other Python libraries.
  • Audacity, VLC, Kodi. Through the various repositories, they are packaged with support enabled for features that do not appear in other distributions.
  • Pidgin. We’ve already discussed this application elsewhere. The Mageia package is very comprehensive, featuring many plugins and messaging protocols not found in other distributions.


A vision for packaging in Mageia

Behind the packaging process, there are defined policies and review procedures through which we aim to ensure the software fits into the system, rather than simply distributing the packages as published by the developers.

Some key features of our packaging:

  • Python. Clear conventions, pyproject, noarch, documentation and dependencies managed by RPM:
  • Java. We avoid duplicate JAR dependencies and maintain separation of components.
  • Firefox. Main package and separate translations. The required language is installed based on the system language.
  • LibreOffice. Installation of the entire suite and the required language based on the system language, in a single metapackage, or separate installation of individual applications.
  • Libraries. Separation of runtime, development and dependencies.
  • KDE/Qt applications. Specific policies for names, libraries and components.
  • Licences. We maintain separation of licences via the ‘Core/Nonfree/Tainted’ repositories.
  • Updates validated by the QA team before reaching the stable release.

What does all this mean for the user?

Most of these decisions do not appear in a screenshot. They do not, on their own, make Plasma’s animations better or cause Firefox to open any faster.

Their value becomes apparent in more everyday situations:

  • Installing an application and automatically obtaining the correct dependencies.
  • Uninstalling it without leaving behind stray files.
  • Updating a library without ending up with multiple incompatible copies.
  • Installing only the languages we need.
  • Installing documentation only when we’re interested in it.
  • Having separate development packages.
  • Maintaining a consistent software base.
  • Receiving updates that have gone through a validation process.

In other words, our users don’t have to constantly think about packaging. If the job is done properly, it simply works.

Conclusions

The main strength of our packaging lies in the way all our teams work together to ensure that each programme fits seamlessly into the whole.

Packaging policies, the separation of components, the handling of dependencies, the careful management of third-party libraries, licence management and the quality control process all form an integrated and coherent system.

The work carried out by our packaging, development and quality assurance teams, whilst not visible to our users or the general public, is one of the most important factors in making our distribution a truly stable and reliable Linux distribution. A great deal of engineering work goes into ensuring that everything fits together to achieve the final result.

Categorías: Blogs Oficiales

MGASA-2026-0457 - Updated erlang package fixes security vulnerabilities

Mageia Security - 27 Septiembre, 2026 - 04:12
Publication date: 27 Sep 2026
Type: security
Affected Mageia releases : 10
CVE: CVE-2026-54886 , CVE-2026-54891 , CVE-2026-54892 , CVE-2026-54893 , CVE-2026-55952 , CVE-2026-55953 Description
SSH SFTP server denial of service via extended channel data infinite loop. (CVE-2026-54886) Plaintext APPLICATION_DATA injected during TLS handshake delivered to client application post-handshake in ssl. (CVE-2026-54891) Plug: quadratic-time decoding of nested query/body parameters enables denial of service. (CVE-2026-54892) Email-derived URL path injection in the Swoosh Microsoft Graph adapter. (CVE-2026-54893) References
SRPMS 10/core
  • erlang-27.3.4.17-1.mga10

MGASA-2026-0455 - Updated python3 & python-pip package fixes security vulnerabilities

Mageia Security - 26 Septiembre, 2026 - 16:57

MGASA-2026-0453 - Updated udisks2 package fixes a security vulnerability

Mageia Security - 25 Septiembre, 2026 - 17:24
Publication date: 25 Sep 2026
Type: security
Affected Mageia releases : 10
CVE: CVE-2026-7867 Description
Local privilege escalation via as-user option spoofing. (CVE-2026-7867) References
SRPMS 10/core
  • udisks2-2.10.1-3.1.mga10

MGAA-2026-0137 - Updated libalkimia package fixes bug

Mageia Security - 25 Septiembre, 2026 - 17:24
Publication date: 25 Sep 2026
Type: bugfix
Affected Mageia releases : 10
Description
Conflicting file between Mageia 9 and Mageia 10 versions of the package can block upgrades to Mageia 10. This update fixes the reported issue. References
SRPMS 10/core
  • libalkimia-8.2.1-1.1.mga10

Fin de soporte para Mageia 9

Blog de Mageia-ES - 25 Septiembre, 2026 - 08:07

En Mageia, hemos completado un hito importante con el lanzamiento de Mageia 10 el 30 de Junio de 2026. Ha sido un paso importante de modernización de nuestro sistema en muchos aspectos, y nuestro caldero ya comienza a cocer para cocinar nuestra próxima versión Mageia 11!

Mageia 9 ha sido sólida como una roca, con 24008 actualizaciones hasta el momento, correcciones de seguridad para nuestros usuarios. Esto se traduce en un arduo trabajo de todos nuestros equipos que hacen que Mageia sea fácil y segura.

Llega el momento de decir adiós a nuestra novena versión y centrarnos en los nuevos retos que propone el mantenimiento de Mageia 10, el desarrollo de Mageia 11 y la adecuación de nuestro software a nuevos tiempos para que soporte las últimas incorporaciones tanto de hardware como de software de terceros empaquetado para nuestros usuarios de Mageia.

Esperamos que todo el trabajo realizado por nuestros colaboradores determine un gran sistema de código abierto de uso fácil, moderno y actualizado para toda nuestra comunidad. Puedes encontrar las características completas de Mageia 10 en las notas de lanzamiento.

El soporte para las versiones previas se extiende a 3 meses después del lanzamiento de la versión más reciente por lo que Mageia 9 dejará de tener soporte el próximo 30 de Septiembre. Por lo tanto, te pedimos que si no lo has hecho ya, consideres migrar a Mageia 10, ya que el soporte para Mageia 9 terminará con las últimas actualizaciones que han sido validadas.

Los métodos de migración se pueden realizar mediante:

  • La aplicación de actualización a versiones mayores de Mageia en la bandeja del sistema (actualmente icono azul de actualización).
  • Usar la línea de comandos como se describe en las notas.

También es posible migrar a Mageia 10 con una instalación limpia mediante las imágenes de instalación clásica. Las imágenes Live pueden usarse para probar Mageia 10 o hacer una instalación limpia, pero no son compatibles para realizar una migración/actualización a la nueva versión de Mageia.

Ten en cuenta que al realizar una instalación limpia, cualquier información no guardada en una partición separada o en una copia de seguridad en un dispositivo externo, será borrada. Comprueba que has realizado los respaldos apropiados.

Si tienes alguna pregunta o necesitas ayuda con la migración, puedes recurrir a nuestros foros que abarcan la mayoría de los idiomas o en el wiki de Mageia.

Categorías: Blogs Oficiales

End of Support for Mageia 9

Blog de Mageia (English) - 25 Septiembre, 2026 - 08:07

At Mageia, we have reached a significant milestone with the release of Mageia 10 on 30 June 2026. It has been a major step towards modernising our system in many respects, and our cauldron is already beginning to simmer as we prepare our next release, Mageia 11!

Mageia 9 has been rock-solid, with 24,008 updates to date, providing security fixes for our users. This is down to the hard work of all our teams, who ensure that Mageia remains easy to use and secure.

The time has come to say goodbye to our ninth release and focus on the new challenges posed by the maintenance of Mageia 10, the development of Mageia 11, and adapting our software to the changing times so that it supports the latest additions in both hardware and third-party software packaged for our Mageia users.

We hope that all the work carried out by our contributors will result in a great open-source system that is user-friendly, modern and up-to-date for our entire community. You can find the full list of features for Mageia 10 in the release notes.

Support for previous versions extends to 3 months after the release of the latest version, so Mageia 9 will no longer be supported as of September 30. We therefore ask that, if you have not already done so, you consider upgrading to Mageia 10, as support for Mageia 9 will end with the latest validated updates.

Migration can be carried out using:

  • The update application for major versions of Mageia in the system tray (currently the blue update icon).
  • Using the command line as described in the notes.

It is also possible to migrate to Mageia 10 with a clean install using the classic installation images. Live images can be used to try out Mageia 10 or perform a clean install, but they are not compatible for migrating to or upgrading to the new version of Mageia.

Please note that when performing a clean install, any data not stored on a separate partition or backed up to an external device will be deleted. Please ensure you have made the necessary backups.

If you have any questions or need help with the migration, you can visit our forums, which cover most languages, or the Mageia wiki.

Categorías: Blogs Oficiales

MGASA-2026-0452 - Updated python-webob packages fix a security vulnerability

Mageia Security - 25 Septiembre, 2026 - 06:02
Publication date: 25 Sep 2026
Type: security
Affected Mageia releases : 10 , 9
CVE: CVE-2026-44889 Description
Location header normalization during redirect leads to open redirect - again References
SRPMS 10/core
  • python-webob-1.8.11-1.mga10
9/core
  • python-webob-1.8.11-1.mga9

MGASA-2026-0451 - Updated unbound packages fixes security vulnerabilities

Mageia Security - 25 Septiembre, 2026 - 06:02
Publication date: 25 Sep 2026
Type: security
Affected Mageia releases : 10 , 9
CVE: CVE-2026-14586 , CVE-2026-32665 , CVE-2026-40622 , CVE-2026-40691 , CVE-2026-41637 , CVE-2026-42955 , CVE-2026-44621 , CVE-2026-44687 , CVE-2026-44690 , CVE-2026-46582 , CVE-2026-50045 , CVE-2026-50046 , CVE-2026-50243 , CVE-2026-50248 , CVE-2026-50251 , CVE-2026-50252 , CVE-2026-52863 , CVE-2026-54478 , CVE-2026-55708 , CVE-2026-55717 , CVE-2026-55973 , CVE-2026-55990 , CVE-2026-55991 , CVE-2026-56416 , CVE-2026-56444 , CVE-2026-77860 , CVE-2026-77955 , CVE-2026-78227 , CVE-2026-80225 , CVE-2026-81634 , CVE-2026-81642 , CVE-2026-82717 , CVE-2026-82720 , CVE-2026-85501 Description
Heap buffer overflow and possible Remote Code Execution when digesting DNSKEY Possible heap buffer overflow during DNSSEC canonicalization CNAME synthesis could lead to heap corruption Possible ZONEMD verification bypass window Use-after-free in DoQ stream output buffer on reset re-transmission Possible degradation of service from continuous queries on the same TCP/DoT connection Use-after-free in DoH stream cleanup code path Retrap: Novel Vulnerabilities to launch Algorithmic Complexity Attacks on DNSSEC 'serve-expired' can bypass Unbound 'wait-limit' Remote DNS-over-QUIC denial of service due to 'quic-size' budget bypass Packet of death for DNSCrypt over TCP Cross-zone wildcard cache poisoning via RRSIG.labels manipulation 'dns-error-reporting: yes' leads to stack buffer overflow Assertion in libngtcp2 when under pressure in high concurrency DNS-over-QUIC environments Libunbound applications configured with 'unwanted-reply-threshold' could eventually be abruptly terminated 'max-global-quota' reset by DNSSEC validation restarts Possible heap use-after-free in an error path when a DoT forwarded query is jostled out 'response-ip'/'rpz' can rewrite BOGUS answers instead of returning SERVFAIL BOGUS configured primary hostname accepted for XFR in auth/rpz zones Date: Attacker supplied '0.0.0.0'/'::' glue triggers defensive full-cache flush Possible cache poisoning attack by mapping source port population per thread Memory corruption could lead to crash and denial of service 'serve-expired-client-timeout' and 'response-ip' CNAME redirect could lead to a crash Packet of death for a DNSCrypt misconfigured Unbound Remote DNS-over-QUIC (DoQ) flow-control assertion failure in libngtcp2 Possible heap buffer overflow when validator canonicalizes RDATA that contains domain name Degradation of resolution service when 'discard-timeout' and 'serve-expired-client-timeout' are combined in unusual configuration Degradation of resolution service from improperly accounted client-terminated DNS-over-QUIC queries Extra fix for CVE-2026-40622 to also clamp the TTL of A/AAAA records disallowing a one-time 'ghost domain' delegation renewal via glue records Off-by-one error in 'harden-below-nxdomain' logic can shadow a stub/forward zone by a legitimate parent's NXDOMAIN A wildcard replay, as another piece of data, triggers poisoning in the serve expired reply path DNS Cookie bypass when combined with proxy-protocol use Privacy/configuration issue when adding local data in views through 'unbound-control' Possible arbitrary code execution during DNSSEC validation Heap overflow with multiple NSID, COOKIE, PADDING EDNS options Crash during DNSSEC validation of malicious content Date: Packet of death with DNSCrypt Another "ghost domain names" attack variant Long list of incoming EDNS options degrades performance Jostle logic bypass degrades resolution performance Degradation of service with unbounded NSEC3 hash calculations Possible cache poisoning via promiscuous records for the authority section Unbounded name compression in certain cases causes degradation of service Use after free and crash under special conditions in RPZ code Possible domain hijacking via promiscuous records in the authority section Cache poisoning via the ECS-enabled Rebirthday Attack Unbounded name compression could lead to Denial of Service Unbound vulnerable to the "DNSBomb" pulsing DoS amplification attack Denial of service when trimming EDE text on positive replies DNSSEC verification complexity can be exploited to exhaust CPU resources and stall DNS resolvers NSEC3 closest encloser proof can exhaust CPU Non-Responsive Delegation Attack Novel "ghost domain names" attack by updating almost expired delegation information Novel "ghost domain names" attack by introducing subdomain delegations Local symlink attack Vulnerability in Domain Parse NXNSAttack Vulnerability in IPSEC module Vulnerability in parsing NOTIFY queries Vulnerability in the processing of wildcard synthesized NSEC records No limit to delegation chaining Ghost domain names attack Incorrect proof processing for NSEC3-signed zone Processing of duplicate CNAME records in a signed zone Empty error packet handling assertion failure References
SRPMS 10/core
  • unbound-1.26.1-1.mga10
9/core
  • unbound-1.26.1-1.mga9

MGASA-2026-0450 - Updated python-gitpython packages fix security vulnerabilities

Mageia Security - 25 Septiembre, 2026 - 06:02
Publication date: 25 Sep 2026
Type: security
Affected Mageia releases : 10 , 9
CVE: CVE-2026-87819 Description
Denial of Service via catastrophic backtracking (ReDoS) in Actor.name_email_regex — commit author/committer field parsing Repository content can impersonate the git directory, leading to arbitrary code execution Residual of GHSA-hmq2-w58f-27jc: the fix validates the `.gitmodules` **name** but the sibling **path** field still reaches `os.makedirs()` unguarded, although GitPython already owns the containment guard References
SRPMS 10/core
  • python-gitpython-3.1.62-1.mga10
9/core
  • python-gitpython-3.1.62-1.mga9

MGAA-2026-0136 - Updated discover package fixes start-up bug

Mageia Security - 25 Septiembre, 2026 - 06:02
Publication date: 25 Sep 2026
Type: bugfix
Affected Mageia releases : 10
Description
In systems that don't have plasma as the desktop discover fails to start. This update fixes the reported issue. References
SRPMS 10/core
  • discover-6.5.5-4.1.mga10

Cooker

Blog de OpenMandriva - 25 Septiembre, 2026 - 00:58
Cooker (development)

Cooker is the OpenMandriva Lx development branch.

This is where developers do the actual work of developing packages and the distro itself. Because of the nature of this continual work process Cooker breaks at times.

If you are not used to problem solving on computers at a very high level Cooker is not for you.

  • arrow_drop_downCOOKER Plasma

    The Plasma Extended version is basically a complete desktop for most non-technical users. It features software from KDE.org and other Qt based software. It includes software for most day to day tasks.

Donate

Blog de OpenMandriva - 25 Septiembre, 2026 - 00:58
Welcome to OpenMandriva!

We are a community-driven initiative dedicated to fostering open source innovation in the realm of operating systems. Since our inception, we have been committed to creating a user-friendly, cutting-edge Linux distribution that empowers users worldwide. However, to continue our mission and enhance our offerings, we need your support.

Why Donate?

Your donations play a crucial role in sustaining and advancing the OpenMandriva project. With your generous contributions, we can:

Downloads

Blog de OpenMandriva - 25 Septiembre, 2026 - 00:58

OpenMandriva flagship release is ROME (rolling)

Current Rock release is OpenMandriva Lx 6.0

Development release is Cooker

Spins are alternative desktops environments

Choose your release The OpenMandriva project offers different image types available for download.
If in doubt, use the full featured Plasma6 x86_64 ISO image. Download the ISO file

Mirror download (sourceforge.net)
Enter the folders, select the release in the list, it should automatically open a download page from a mirror nearby your location.
If in doubt, go to OpenMandriva homepage at SourceForge and click the big green button “Download”

Frequently asked questions

Blog de OpenMandriva - 25 Septiembre, 2026 - 00:58
Questions and Answers
  • arrow_drop_downTell readers about the founding of Open Mandriva This is essentially just old history - maybe the most interesting part is that it means we are one of the oldest distributions still alive today.
    When Mandriva (previously Mandrake) went out of business, the community didn’t want to let the distribution die, so it was turned over to a team consisting of previous contributors, and people from related similar projects (Unity Linux, Ark Linux) joined forces to form OpenMandriva.
    We agreed with what remained of Mandriva on terms for all further development:
    License
  • arrow_drop_downWhat does OpenMandriva inherit from Mandrake? Technology? Organization? Philosophy? The original source code;
    The initial team, or part of it;
    The idea of building an operating system that is simple enough for someone who has never seen Linux to get productive with, without dumbing it down to the point that it stops being useful to experts.
    OpenMandriva philosophy is inspired by the Open Source principles philosophy.
  • arrow_drop_downAny stats about downloads, commits, developers? Given we are an Open Source project with quite a few mirrors and bittorrent downloads, and we have no idea how many people share their download with others, it is impossible to get accurate numbers.
    We can get documented stats only from SourceForge mirror. Maybe worth to mention that many users and/or newcomers are invited to download and test the latest ISO images snapshots, during development cycle in-between the officially announced releases, directly from our build server, ABF (cf. Forum topics Most recent Cooker ISO and Most recent ROME (rolling) ISO which we keep constantly up-to-date).
    Of course we have more accurate numbers about developers and commits.
    There are 7 main developers, and a few people who submit a patch once in a while.
    There have been 82350 commits in the last year, out of which 7323 were in the last month.
    The commits go to our repositories OpenMandriva Association and OpenMandriva Software and the packages are built on ABF: [1] [2]
  • arrow_drop_downHow is OpenMandriva organized, and how are decisions made? OpenMandriva has 2 main entities:
    Council for what concerning the legal/paperworks, PR and organization side;
    Technical Committee for what concerning the products’ technical development side.
    The decisions are made depending on the specific subject however more often than not they are virtually identical pertaining to both sides.
    When at all possible we aim to reach consensus for final decisions. Crucial help is provided by the shared target and common sense.
    People who have been contributing consistently over some time are invited into the relevant entities.
  • arrow_drop_downHow does the Association interact with the community?
    • Main website /
      (News)

Get involved

Blog de OpenMandriva - 25 Septiembre, 2026 - 00:58
Give time

If you have time, we welcome your help in various areas:

Development

Check the developers documentation, join the conversation, and have a look at the bug-tracking system and to get in touch with the developers community and get things done

Writing

Help us improve the documentation, materials and communication

Translation

Translators, help us translate web materials, OpenMandriva Lx and other projects

Keep the Community alive

Participate in the forum, write your experience with Rock or ROME, share your knowledge, publish your desktop screenshots, help the other users, or even just chat

Feed