Новости Joomla

‼️ 👩‍💻 Обновление безопасности для Tassos Framework!

‼️ 👩‍💻 Обновление безопасности для Tassos Framework!

7 января 2026 года греческому разработчику Тассосу Мариносу сообщили об уязвимости в системном плагине Tassos Framework, который входит в состав его расширений для Joomla.

⚠️ Проблема затрагивает следующие расширения:
- Convert Forms - конструктор форм обратной связи для Joomla
- EngageBox - конструктор всплывающих окон для Joomla
- Google Structured Data - пакет плагинов микроразметки для Joomla
- Advanced Custom Fields - пакет плагинов пользовательских полей (видео-сервисы, карты и иже с ними)
- Smile Pack - пакет расширений
- MailChimp Auto-Subscribe

Незамедлительно была проведена полная внутренняя проверка кода, внедрены дополнительные меры проверки и повышения безопасности, а также выпущены исправленные версии всех затронутых расширений. Проблема полностью решена.

👉 Суть уязвимости.
Уязвимость заключалась в том, как плагин Tassos Framework обрабатывал определенные AJAX-запросы через com_ajaxточку входа Joomla. При определенных условиях внутренняя функциональность фреймворка могла быть вызвана без надлежащих ограничений.

В худшем случае это могло позволить неавторизованному злоумышленнику читать файлы, доступные веб-серверу. Это также могло позволить удалять файлы с сервера при выполнении определенных условий.

При определенных обстоятельствах запросы к базе данных могли быть изменены для извлечения данных из базы данных Joomla. В совокупности эти возможности потенциально могли быть использованы для повышения уровня доступа и выполнения несанкционированного кода.

В настоящее время нет никаких доказательств того, что эта уязвимость была использована в реальных условиях.

Немедленно обновите расширения до безопасных версий (Joomla 4/5/6 | Joomla 3):
- Convert Forms - v5.1.1 / v.4.1.1
- EngageBox - v.7.1.1 / v,6,3,9
- Google Structured Data - v.6.1.1 / v.5.6.9
- Advanced Custom Fields - v.3.1.1 / v.2.8.10
- Smile Pack - v.2.1.1 / v.1.2.4.
- MailChimp Auto-Subscribe - v.5.1.1+ / v.5.0.4

Все указанные версии включают в себя релиз безопасности плагина Tassos Framework System Plugin v6.0.62.

Если у вас установлено несколько расширений Tassos, достаточно обновить только одно, чтобы применить патч. Однако всегда рекомендуется обновлять все расширения.

@joomlafeed

👩‍💻 Joomla включена в программу Google Summer of Code 2026.

👩‍💻 Joomla включена в программу Google Summer of Code 2026.

Google Summer of Code (GSoC) - программа компании Google, которая позволяет участникам программы под руководством опытных наставников писать код для организаций, занимающейся открытым исходным кодом. Joomla принимает участие в этой программе не в первый раз и в 2026 году снова включена в список GSoC. Для программы утверждается список "идей", воплотить которые должны участники под руководством наставников.

Проекты Joomla в рамках программы GSoC 2026.

Проект I: Ajax-бэкенд.
- Действия в административной панели без необходимости обновлять страницу.
- Автоматическое сохранение содержимого во время редактирования.
- Расширенный фильтр - поиск и фильтрация по пользовательским полям.

Проект II: Автоматизация рабочих процессов (workflow + task scheduler).
Joomla имеет функцию процессов и планировщика задач. Теперь эти две функции следует объединить, чтобы пользователь мог настраивать назначенные рабочие процессы таким образом, чтобы переходы выполнялись автоматически, с возможностью точного определения времени. Должна быть возможность создавать циклы или прямые запланированные рабочие процессы. Предполагается, что интерфейс должен учитывать хороший пользовательский опыт, удобство использования и современные стандарты доступности. Ожидается, что будет добавлен интерфейс для управления процессами и их расписанием на страницах категорий и материалов. Так же ожидается, что сторонние компоненты также смогут воспользоваться этим функционалом.

Проект III: Мультикатегории.
В настоящее время Joomla! не позволяет назначать один элемент нескольким категориям. Хотя система тегов часто используется в качестве замены, существует острая потребность в нативной поддержке нескольких категорий, чтобы привести Joomla! в соответствие с другими современными системами управления контентом.

Проект IV: Обучение с подкреплением на основе отзывов переводчиков.
Joomla собирается использовать автоматический перевод документации. В каждом языке есть свои специфические слова, характерные для Joomla. Предполагается обучать языковые модели, используя обратную связь от переводчиков, чтобы постоянно улучшать качество переводов и учитывать специфические языковые особенности Joomla.

Принять участие GSoC 2026
Подробнее о проектах Joomla GSoC 2026
Чат GSoC в Mattermost (международное сообщество Joomla)

Вышли релизы Joomla 6.0.3 и Joomla 5.4.3

Релиз Joomla 6.0.3 и Joomla 5.4.3

Проект Joomla рад сообщить о выпуске Joomla 6.0.3 и Joomla 5.4.3. Это релиз исправлений ошибок и улучшений для серии Joomla 6.0 и Joomla 5.4.

1   Вниз
0 Пользователей и 1 Гость просматривают эту тему.
  • 11 Ответов
  • 5517 Просмотров

Перенагрузка сервера - вариант решения проблемы...
« : 26.09.2006, 22:38:47 »
Столкнулся с проблемой - перенагрузка на сервер по вине скриптов Джумлы

то есть - скрипт загружается и по несколько часов выполняется по циклу, не завершаясь.
Хостинг - Hostpro




Цитировать
Добрый день, за последние пару дней ко мне как веб-програмисту
обращалось более десяти людей с идентичными проблемами.
Все они использовали движок Joomla. Всем им ихние хостеры
заблокировали акаунты.
На форуме движка Joomla есть топик где десятки людей рапортуют о такой
проблеме.

Локализовать проблемный участок мне удалось лишь частично. Это
практически любой компонент который в цикле делает выборки из СУБД. Но
"криворукие" програмисты Joomla используют подавление ошибок через @ и
не делают обработки ошибок/исключений если mysql_query или
mysql_result возвращают не тот результат или вобще утрачен конект.
Практически если во время работы скрипта утрачивается конект к БД,
скрипт завершить работу может только по таймауту (php.ini:
max_execution_time)

Предполагаю что на вашем хостинге кроме моих есть ещё много сайтов
которые используеют этот популярный движок, но "оптимизировать"
владельцам вряд ли удастся пока Joomla не выпустит обновление.

Так же, я был удивлен что max_execution_time у вас по умолчанию 7200
секунд (это 2 часа).
Кардинальным решением проблемы до выхода обновлений Joomla я считаю
выставить всем или каждому лично max_execution_time=5-15 секунд, т.е.
если проблема зацикливания проявится, скрипт не будет 2 часа грузить
CPU, а через 5 секунд (достаточно для нормальной работы любого
веб-сайта) будет принудеительн озавершен интерпретатором PHP.

В этом сайте я уже установил в скриптах
set_time_limit(5);
и ходатайствую об открытии доступа к этой папке.
Возможно такая просьба недавно приходила по e-mail от другого человека
который курирет этот сайт.


ahcu> Здравствуйте, .

ahcu>     Ваш сайт создаёт нагрузку на нашем сервере. Это негативно
ahcu>     сказывается на всей работе сервера. Оптимизируйте пожалуйста
ahcu>     данный скрипты. Это не нормально когда php скрипт работает такое
ahcu>     количество времени.

если такое происходит - мне порекомендовали прописать в
configuration.php
строчку
set_time_limit(5);

это должно предотвратить цикличное выполнение завснувшего скрипта и перенагрузку на сервер из-за етого.

Вот здесь человек запостил свое мнение:
http://php.com.ua/forum/viewtopic.php?t=6628


Далее  нашел вот такую инфу о возможности зависа самой MySQL

"I suppose it's some kind of stack overflow in the IF() function."
http://bugs.mysql.com/bug.php?id=21476
« Последнее редактирование: 26.09.2006, 22:42:47 от ukrmedshpora »
Записан
*

smart

  • Администратор
  • 6478
  • 1318 / 15
  • Хочешь сделать хорошо — сделай!
Re: Перенагрузка сервера - вариант решения проблемы...
« Ответ #1 : 26.09.2006, 23:22:14 »
Цитировать
Локализовать проблемный участок мне удалось лишь частично. Это практически любой компонент который в цикле делает выборки из СУБД. Но "криворукие" програмисты Joomla используют подавление ошибок через @ и не делают обработки ошибок/исключений если mysql_query или mysql_result возвращают не тот результат или вобще утрачен конект.
мдя, интересно, а автор этих строк вообще смотрел как в самой Joomla происходит работа с БД? то, что он нашел проблему в галерее DatsoGallery, где за многовековую историю компонента (сначала AkoGallery, затем PonyGallery) набралось куча мусора, отнюдь не означает, что виновата Joomla...

В Joomla и ее расширениях, вся работа с базой данных осуществляется через 2 класса database и mosDBTable. И поверьте, единственное место, где в них происходит подавление вывода ошибки, это при подключении к БД, и то, сама ошибка прекрасно обрабатывается... В этом вы можете сами убедиться внимательно изучив код внутри файла /includes/database.php. Поэтому все расширения, которые используюьт предложенный ядром системы интерфейс работы с базой данных описанных проблем создавать не могут...

Так что приведенные заявления, к самой Joomla никакого отношения не имеют... А что касается качества сторонних расширений, то это уже собственно на совести их разработчиков.
Записан

Re: Перенагрузка сервера - вариант решения проблемы...
« Ответ #2 : 26.09.2006, 23:40:46 »
но человек ведь не спец в джумле - он посмотрел только кусок кода - увидел ошибку - и сообщил, ведь хочет помочь человек
http://forge.joomla.org/sf/tracker/do/viewArtifact/projects.joomla/tracker.bugs/artf6121?_message=1159293810550
Записан
*

saschaAG

  • Новичок
  • 5
  • 5 / 1
Re: Перенагрузка сервера - вариант решения проблемы...
« Ответ #3 : 26.09.2006, 23:44:29 »
Странные люди

 :o :o :o

Такие и машин то себе не покупают потому что те об стены бетонные мнутся, ломаются если заднию на полной скорости врубить.
Криворукое автомобилестроение!!!!!!!!
Записан

Re: Перенагрузка сервера - вариант решения проблемы...
« Ответ #4 : 26.09.2006, 23:45:34 »
ответ по аське от автора приведенных выше строк:
"Ядро системы Joomla никак не обрабатывает ошибку утраты конекта к БД которая появляется в т.ч. из-за бага http://bugs.mysql.com/bug.php?id=21476
Когда $this->_resource уже ни на что не указывает, @subpackage Database будет продолжать пытаться выполнить запрос и/или рапортовать о ошибке выполнения запроса (если включен дебаг) но mysql_error() тоже не сможет выполниться т.к. переданный ей  $this->_resource не существует
"
@
 /**
 * Execute the query
 * @return mixed A database resource if successful, FALSE if not.
 */
 function query() {
  global $mosConfig_debug;
  if ($this->_debug) {
   $this->_ticker++;
     $this->_log[] = $this->_sql;
  }
  if ($this->_limit > 0 || $this->_offset > 0) {
   $this->_sql .= "\nLIMIT $this->_offset, $this->_limit";
  }
  $this->_errorNum = 0;
  $this->_errorMsg = '';
  $this->_cursor = mysql_query( $this->_sql, $this->_resource );
  if (!$this->_cursor) {
   $this->_errorNum = mysql_errno( $this->_resource );
   $this->_errorMsg = mysql_error( $this->_resource )." SQL=$this->_sql";
   if ($this->_debug) {
    trigger_error( mysql_error( $this->_resource ), E_USER_NOTICE );
    //echo "<pre>" . $this->_sql . "</pre>\n";
    if (function_exists( 'debug_backtrace' )) {
     foreach( debug_backtrace() as $back) {
      if (@$back['file']) {
       echo '<br />'.$back['file'].':'.$back['line'];
      }
     }
    }
   }
   return false;
  }
  return $this->_cursor;
 }


что будет с этим скриптом если $this->_resource не будет указывать на валидный конект?
@

http://phpclub.ru/paste/index.php?show=1462
« Последнее редактирование: 27.09.2006, 00:07:19 от ukrmedshpora »
Записан
*

smart

  • Администратор
  • 6478
  • 1318 / 15
  • Хочешь сделать хорошо — сделай!
Re: Перенагрузка сервера - вариант решения проблемы...
« Ответ #5 : 27.09.2006, 00:23:55 »
Цитата: ukrmedshpora от 26.09.2006, 23:40:46
но человек ведь не спец в джумле - он посмотрел только кусок кода - увидел ошибку - и сообщил, ведь хочет помочь человек
я понимаю что хочет, но я очень сомневаюсь, что у него есть право безапелляционно называть разработчиков Joomla "криворукими"...

Цитата: ukrmedshpora от 26.09.2006, 23:45:34
Когда $this->_resource уже ни на что не указывает, @subpackage Database будет продолжать пытаться выполнить запрос и/или рапортовать о ошибке выполнения запроса
когда $this->_resource не валиден, то после строки:


$this->_cursor = mysql_query( $this->_sql, $this->_resource ); 


переменная $this->_cursor будет иметь значени FALSE, затем мы попадем в блок обработки ошибок (да, ошибки не отработаются, бо $this->_resource не валиден, но беды не произойдет) и затем функция query вернет значение FALSE. И где тут возможно зацикливание?

Если кто-то из сторонних разработчиков игнорирует возвращаемый результат, то разработчики Joomla тут не виноваты, хотя все-таки стоило бы сделать более полную обработку ошибок...

P.S. кстати, приведенная ошибка, по которой MySQL может терять коннект, подтверждена пока вроде только для версии 5.0.22, а Joomla официально вообще-то MySQL 5.x не поддерживает. Совместимость с пятеркой обещали в версии 1.5:

Цитировать
To achieve cross database support, a database abstraction library will be implemented. Core scripting will also be improved to prepare for compatibility with other platforms.  The first step towards this goal will be compatability with MySQL 5.0 which is tentatively slated for Joomla! 1.5
« Последнее редактирование: 27.09.2006, 00:37:44 от smart »
Записан

Re: Перенагрузка сервера - вариант решения проблемы...
« Ответ #6 : 27.09.2006, 00:45:53 »
> я понимаю что хочет, но я очень сомневаюсь, что у него есть право
> безапелляционно называть разработчиков Joomla "криворукими"...
я был не в курсе чем разработчик com_joomfish или com_dartsogallery отличается от разработчика Joomla, т.к. джумлу в глаза не видел, но надо было в кратчайшие сроки добиться разблокировки акаунта хостером. Извините что выразился не по адресу

> Если кто-то из сторонних разработчиков игнорирует возвращаемый результат, то
> разработчики Joomla тут не виноваты, хотя все-таки стоило бы сделать более полную
> обработку ошибок...
если кто-то из разработчиков софта вешает Windows 98 и она от этого падает то винить будут Билли. Почему централизовано не сделать full-stop скрипта при первом неотработанном SQL запросе? Или неотработка SQL запроса это не "Fatal error" а всего лишь "Notice"?

> P.S. кстати, приведенная ошибка, по которой MySQL может терять коннект, подтверждена
> пока вроде только для версии 5.0.22, а Joomla официально вообще-то MySQL 5.x не
 > поддерживает. Совместимость с пятеркой обещали в версии 1.5:
Баг проверен на трех разных серверах MySQL 4.1
Записан
*

smart

  • Администратор
  • 6478
  • 1318 / 15
  • Хочешь сделать хорошо — сделай!
Re: Перенагрузка сервера - вариант решения проблемы...
« Ответ #7 : 27.09.2006, 01:05:02 »
Цитата: ukrmedshpora от 27.09.2006, 00:45:53
если кто-то из разработчиков софта вешает Windows 98 и она от этого падает то винить будут Билли.
если ставить задачей кого-то обвинить, то обвинить можно кого угодно...

Цитата: ukrmedshpora от 27.09.2006, 00:45:53
Почему централизовано не сделать full-stop скрипта при первом неотработанном SQL запросе? Или неотработка SQL запроса это не "Fatal error" а всего лишь "Notice"?
Можно и останавливать, а можно возложить это на разработчиков расширений и предоставить им решать, является ли это критической ошибкой, или нет... Хотя конечно, проблему потери коннекта с базой, должно решать ядро...

Цитата: ukrmedshpora от 27.09.2006, 00:45:53
Баг проверен на трех разных серверах MySQL 4.1
ни разу не сталкивались, хотя у нас на сервере стоит 4.1...

Кстати, мне кажется, стоит задуматься вот еще о чем: если такая ошибка повторяется, значит коннект постоянно падает? Может быть предложить хостеру вместо отключения аккаунтов решить проблему с сервером?
Записан

Re: Перенагрузка сервера - вариант решения проблемы...
« Ответ #8 : 27.09.2006, 01:23:10 »
Интересно так быть посредником в перепалке двух спецов ))

> если ставить задачей кого-то обвинить, то обвинить можно кого угодно...
задача была доказать хостеру что "оптимизировать кривые скрипты" работающие бесконечно не представляется возможным ибо они чужие

> ни разу не сталкивались, хотя у нас на сервере стоит 4.1...
так это зависит от размера злосчастного thread_stack
увеличивать его хостер категорично отказался

Вот ответ от сотрудника MySQL который подтвердил http://bugs.mysql.com/bug.php?id=21476
[19:48] <sveta> в общем от меня далее мало зависит, как этот баг фиксить будут, но спросить могу
[20:01] <sveta> вообще раз баг verified, то его фиксить будут
[20:01] <sveta> и странно, что ещё не фиксят: я узнаю почему
[20:43] <sveta> .msg Yurik послала письмо человеку, ответственному за то, чтобы верифицированные баги фиксились
Записан
*

smart

  • Администратор
  • 6478
  • 1318 / 15
  • Хочешь сделать хорошо — сделай!
Re: Перенагрузка сервера - вариант решения проблемы...
« Ответ #9 : 27.09.2006, 01:41:49 »
Цитата: ukrmedshpora от 27.09.2006, 01:23:10
Интересно так быть посредником в перепалке двух спецов ))
бывает...

Цитата: ukrmedshpora от 27.09.2006, 01:23:10
задача была доказать хостеру что "оптимизировать кривые скрипты" работающие бесконечно не представляется возможным ибо они чужие
а я бы начинал разбирательство с непредоставления ими услуг, т.е. рабочего мускла...

Цитата: ukrmedshpora от 27.09.2006, 01:23:10
так это зависит от размера злосчастного thread_stack
увеличивать его хостер категорично отказался
Интересненько, а какое значение там установлено? Судя по конфигурации сервера, у нас thread_stack:  196608

Цитата: ukrmedshpora от 27.09.2006, 01:23:10
Вот ответ от сотрудника MySQL который подтвердил
да верю, верю... просто на странице с багом, где написано verified, указана была версия 5.0.22, и вроде не было указаний на линейку 4.1...
Записан

Re: Перенагрузка сервера - вариант решения проблемы...
« Ответ #10 : 27.09.2006, 01:57:28 »
Мне лично сапорт ответил (после указания им ссылки на баг):

У нас из соображений стабильности сервера:
thread_cache_size=128
К сожалению, изменению это не подлежит.
=

Я сам посмотрел в настройки Мускуеля:
 table cache     1,024
table type    MyISAM
thread cache size    128
thread stack    196,608

Записан
*

smart

  • Администратор
  • 6478
  • 1318 / 15
  • Хочешь сделать хорошо — сделай!
Re: Перенагрузка сервера - вариант решения проблемы...
« Ответ #11 : 27.09.2006, 02:37:13 »
Цитата: ukrmedshpora от 27.09.2006, 01:57:28
table cache     1,024
table type    MyISAM
thread cache size    128
thread stack    196,608
а у нас:

table cache     500
table type    MyISAM
thread cache size    12
thread stack    196,608

странно... конечно, с базой у нас иногда проблемы бывают, но потерь коннекта насколько помню не было...
Записан
1   Вверх
Чтобы оставить сообщение,
Вам необходимо Войти или Зарегистрироваться
 

Проблемы запуска сайта на локальном сервере

Автор uragan87

 Ответов: 0
Просмотров: 2741 		Последний ответ 04.06.2013, 23:26:17
от uragan87
проблемы при установке

Автор saymonik

 Ответов: 4
Просмотров: 6435 		Последний ответ 01.12.2011, 22:08:52
от DPavlov
Установка Joomla в поддиректорию...Есть проблемы

Автор Keno

 Ответов: 13
Просмотров: 12391 		Последний ответ 25.05.2010, 13:46:30
от garnir
Проблемы при переносе в другую директорию

Автор esistema

 Ответов: 3
Просмотров: 4138 		Последний ответ 12.10.2009, 16:39:01
от Jekos
проблемы с переносом на хост

Автор robotwerder

 Ответов: 8
Просмотров: 3999 		Последний ответ 18.06.2009, 15:58:12
от robotwerder