amazonlinux

Stars and mentions

Last 30 days, Oct 4 – Nov 2

GitHub stars5

mentions45

UTC days · repositories amazonlinux owns1 repositories

Package downloads

No package download history available yet.

Top repositories

amazonlinux’s repositories ranked by new stars, as on trending.

#	Repository	Activity ⓘ	Stars	Forks	Contributors
1
2
3
4
5
6
7
8
9
10

Contributes to

Repositories outside amazonlinux’s account where amazonlinux opened or reviewed pull requests in the past 365 days.

Who noticed amazonlinux

Everyone who starred or forked amazonlinux’s repositories since the archive began in 2011.

Notable accounts

Ordered by the stars their own repositories have received.

Biggest fans

Accounts that starred the most of these repositories.

Breakout weeks

Each repository’s best week of new stars, with the release published around it.

Mentions

45posts

Nov 30 posts

Zenn · Nov 2 · @77nnaapp · amazonlinux/amazon-linux-2023
[AWS]作成したRDSの構成をterraform化するこのページでは、EC2のみを Terraform化して一旦、削除→Terraform から再構築を実施ローカル側のAWS CLIのプロファイルが残っているか C:\Users\haruk>aws configure list-profiles aws-lab AWSに接続できるか確認 C:\Users\haruk>aws sts get-caller-identity --profile aws-lab { "UserId": "AIDxxxxxxxxxxxxxxxx", "Account": "xxxxxxxxxxxxx", "Arn": "arn:aws:iam::xxxxxxxxxxxxx:user/tidus" } ステップ1：リージョンを確認 C:\Users\haruk>aws configure get region --profile aws-lab ap-northeast-1 ステップ2：VPCを確認 C:\Users\haruk>aws ec2 describe-vpcs --profile aws-lab --region ap-northeast-1 --query "Vpcs[].{VpcId:VpcId,CidrBlock:CidrBlock,IsDefault:IsDefault,Name:Tags[?Key=='Name']|[0].Value}" --output table +----------------------------------------------------------------------- | DescribeVpcs | +--------------+------------+--------------+--------------------------+ | CidrBlock | IsDefault | Name | VpcId | +--------------+------------+--------------+--------------------------+ | 10.0.0.0/16 | False | aws-lab-vpc | vpc-0f9046xxxxxxxxx | | 10.10.0.0/16| False | VPC-A | vpc-0070d4xxxxxxxxx | +--------------+------------+--------------+--------------------------+ ステップ3：サブネットを確認 C:\Users\haruk>aws ec2 describe-subnets --profile aws-lab --region ap-northeast-1 --filters "Name=vpc-id,Values=vpc-0f90469347a521370" --query "Subnets[].{SubnetId:SubnetId,Name:Tags[?Key=='Name']|[0].Value,Cidr:CidrBlock,AZ:AvailabilityZone,PublicIP:MapPublicIpOnLaunch}" --output table +--------------------------------------------------------------------------------------------------------- | DescribeSubnets | +-----------------+--------------+-----------------------------+-----------+----------------------------+ | AZ | Cidr | Name | PublicIP | SubnetId | +-----------------+--------------+-----------------------------+-----------+----------------------------+ | ap-northeast-1c| 10.0.3.0/24 | aws-lab-public-subnet-1c | False | subnet-04d81e2160e876429 | | ap-northeast-1a| 10.0.2.0/24 | aws-lab-private-subnet-1a | False | subnet-0d92abfb23d13d1b1 | | ap-northeast-1a| 10.0.1.0/24 | aws-lab-public-subnet-1a | True | subnet-0d812977405516891 | +-----------------+--------------+-----------------------------+-----------+----------------------------+ ステップ4：ルートテーブルを確認 aws ec2 describe-route-tables --profile aws-lab --region ap-northeast-1 --filters "Name=vpc-id,Values=vpc-0f90469347a521370" --query "RouteTables[].{RouteTableId:RouteTableId,Name:Tags[?Key=='Name']|[0].Value,Associations:Associations[].SubnetId,Routes:Routes[].{Destination:DestinationCidrBlock,Gateway:GatewayId,NAT:NatGatewayId}}" --output json ステップ5：セキュリティグループを確認 aws ec2 describe-security-groups --profile aws-lab --region ap-northeast-1 --filters "Name=vpc-id,Values=vpc-0f90469347a521370" --query "SecurityGroups[].{Name:GroupName,GroupId:GroupId,Description:Description,Ingress:IpPermissions[].{Protocol:IpProtocol,FromPort:FromPort,ToPort:ToPort,IPRanges:IpRanges[].CidrIp,SourceSG:UserIdGroupPairs[].GroupId},Egress:IpPermissionsEgress[].{Protocol:IpProtocol,FromPort:FromPort,ToPort:ToPort,IPRanges:IpRanges[].CidrIp}}" --output json ステップ6：EC2の一覧を確認 C:\Users\haruk>aws ec2 describe-instances --profile aws-lab --region ap-northeast-1 --filters "Name=vpc-id,Values=vpc-0f90469347a521370" --query "Reservations[].Instances[].{InstanceId:InstanceId,Name:Tags[?Key=='Name']|[0].Value,State:State.Name,Type:InstanceType,Subnet:SubnetId,PrivateIP:PrivateIpAddress,PublicIP:PublicIpAddress,SG:SecurityGroups[].GroupId}" --output table +-------------------------------------------- | DescribeInstances | +-------------+----------------------------+ | InstanceId | i-03deec345a9e8bxxx | | Name | aws-lab-web-1a | | PrivateIP | 10.0.1.122 | | PublicIP | 43.207.xxx.xxx | | State | running | | Subnet | subnet-0d812977405516xxx | | Type | t3.micro | +-------------+----------------------------+ || SG || |+----------------------------------------+| || sg-080da58036901fxxx || |+----------------------------------------+| ステップ7：RDSの設定を確認 C:\Users\haruk>aws rds describe-db-instances --profile aws-lab --region ap-northeast-1 --query "DBInstances[].{Identifier:DBInstanceIdentifier,Status:DBInstanceStatus,Engine:Engine,Version:EngineVersion,Class:DBInstanceClass,Endpoint:Endpoint.Address,Port:Endpoint.Port,Public:PubliclyAccessible,SubnetGroup:DBSubnetGroup.DBSubnetGroupName,Vpc:DBSubnetGroup.VpcId,MultiAZ:MultiAZ,Storage:AllocatedStorage,SG:VpcSecurityGroups[].VpcSecurityGroupId}" --output json [ { "Identifier": "aws-lab-mysql", "Status": "available", "Engine": "mysql", "Version": "8.4.11", "Class": "db.t4g.micro", "Endpoint": "aws-lab-mysql.c94e6oggkxxx.ap-northeast-1.rds.amazonaws.com", "Port": 3306, "Public": false, "SubnetGroup": "default-vpc-0f904xxxxxxxxxx", "Vpc": "vpc-0f904xxxxxxxxxx", "MultiAZ": false, "Storage": 20, "SG": [ "sg-0622xxxxxxxxxxxx" ] } ] ステップ8：VPCエンドポイントを確認 C:\Users\haruk>aws ec2 describe-vpc-endpoints --profile aws-lab --region ap-northeast-1 --filters "Name=vpc-id,Values=vpc-0f90469347a521370" --query "VpcEndpoints[].{Id:VpcEndpointId,Service:ServiceName,Type:VpcEndpointType,State:State,Vpc:VpcId,SubnetIds:SubnetIds,RouteTableIds:RouteTableIds,SG:Groups[].GroupId}" --output json [ { "Id": "vpce-023dxxxxxxxxxxx", "Service": "com.amazonaws.ap-northeast-1.s3", "Type": "Gateway", "State": "available", "Vpc": "vpc-0f904693xxxxxxxxxxxxxxx", "SubnetIds": [], "RouteTableIds": [ "rtb-0700c7xxxxxxxxxxxx" ], "SG": [] } ] ステップ9：インターネットゲートウェイを確認 C:\Users\haruk>aws ec2 describe-internet-gateways --profile aws-lab --region ap-northeast-1 --filters "Name=attachment.vpc-id,Values=vpc-0f90xxxxxxxxx" --query "InternetGateways[].{Id:InternetGatewayId,Name:Tags[?Key=='Name']|[0].Value,VpcAttachments:Attachments[].VpcId,State:Attachments[].State}" --output table +------------------------------------------ | DescribeInternetGateways | +------------------------+---------------+ | Id | Name | +------------------------+---------------+ | igw-0e0734431b1625049 | aws-lab-igw | +------------------------+---------------+ || State || |+--------------------------------------+| || available || |+--------------------------------------+| || VpcAttachments || |+--------------------------------------+| || vpc-0f904xxxxxxxxxxxxxx || |+--------------------------------------+| ステップ1：Terraform用フォルダを作成 mkdir C:\Users\haruk\terraform-ec2-rds cd C:\Users\haruk\terraform-ec2-rds ステップ2：main.tf を作成 notepad main.tf terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 6.0" } } } provider "aws" { region = "ap-northeast-1" profile = "aws-lab" } 既存のVPCを参照するだけ data "aws_vpc" "lab" { id = "vpc-0f90469347a521370" } ステップ4：EC2設定のインポートを追記 import { to = aws_instance.web id = "i-03deec345a9e8b502" } ステップ5：EC2の設定を自動生成 terraform plan -generate-config-out=generated.tf ↑何してる？ import ブロックを読み取る AWS上の既存EC2の設定を取得する generated.tf というファイルにTerraformコードを生成する取り込み計画を表示するエラーが出た ↓エラー内容競合する項目内容 primary_network_interface と associate_public_ip_address ネットワークインターフェースとパブリックIPの設定 ipv6_address_count と ipv6_addresses IPv6アドレスの指定方法 ↓下記２か所を削除 ① primary_network_interface を削除次のブロック全体を削除します。 primary_network_interface { network_interface_id = "eni-06da52f5800ebb70f" } ② IPv6の設定を修正次の2行を削除してください。 ipv6_address_count = 0 ipv6_addresses = [] 次のステップ terraform plan Plan: 1 to import, 0 to add, 0 to change, 0 to destroy. 次のステップ terraform apply EC2の元ができたので、まずは、既存EC2を削除する前に、Terraformから同じ構成を再作成できる状態に整えるところから進めます。RDSと既存ネットワークは維持します。手順1：現在のTerraform設定を確認する terraform state list C:\Users\haruk\terraform-ec2-rds>terraform state list data.aws_vpc.lab aws_instance.web これはTerraformが現在管理しているリソースの一覧を表示するだけ手順2：EC2の設定ファイルを整理する type main.tf 下記設定のみを削除する import { to = aws_instance.web id = "i-03deec345a9e8b502" } 手順4：EC2を再作成できる設定か確認する C:\Users\haruk\terraform-ec2-rds>findstr /n /i "user_data ami instance_type subnet_id vpc_security_group_ids" generated.tf 6: ami = "ami-0a940816f3c484aa0" 17: instance_type = "t3.micro" 26: subnet_id = "subnet-0d812977405516891" 34: user_data = null 35: user_data_replace_on_change = null 37: vpc_security_group_ids = ["sg-080da58036901fcbb"] 手順5：OSを確認する sh-5.2$ cat /etc/os-release NAME="Amazon Linux" VERSION="2023" ID="amzn" ID_LIKE="fedora" VERSION_ID="2023" PLATFORM_ID="platform:al2023" PRETTY_NAME="Amazon Linux 2023.12.20261026" ANSI_COLOR="0;33" CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2023" HOME_URL="aws.amazon.com" DOCUMENTATION_URL="docs.aws.amazon.com" SUPPORT_URL="aws.amazon.com" BUG_REPORT_URL="amazonlinux/amazon-linux-2023" VENDOR_NAME="AWS" VENDOR_URL="aws.amazon.com" SUPPORT_END="2029-06-30" 手順6：起動時スクリプトを作る generated.tf　にて下記編集 user_data = null user_data_replace_on_change = null 下記に修正 user_data = <<-EOF #!/bin/bash dnf install -y mariadb105 EOF user_data_replace_on_change = false これで、新しくEC2を作成したときにMariaDBクライアントを自動インストールする設定になります。手順7：設定を検証する C:\Users\haruk\terraform-ec2-rds>terraform validate Success! The configuration is valid. これはTerraformの設定ファイルの構文や整合性を検証するコマンド手順8：Planを確認する terraform plan Plan: 1 to add, 0 to change, 1 to destroy. ただし、実行前に重要な注意点があります。インスタンスIDとパブリックIPが変わります。 EC2内に手動で保存したデータや設定は、新しいEC2には引き継がれません。 RDS自体はこのPlanの対象ではありません。 user_data によるMariaDBクライアントのインストールは、新しいEC2の起動時に実行されます。ただし、スクリプトの実行成否は別途確認が必要です。手順2：Terraformの管理状態からEC2を外す C:\Users\haruk\terraform-ec2-rds>terraform state rm aws_instance.web Removed aws_instance.web Successfully removed 1 resource instance(s). 手順2：AWSコンソールから既存EC2を削除する AWSコンソールで EC2 → インスタンスを開きます。リージョンが東京（ap-northeast-1）になっていることを確認します。インスタンスID i-03deec345a9e8bxxx を選択します。インスタンスの状態が「実行中」であることを確認し、必要なデータがないことを確認します。インスタンスの状態 → インスタンスを終了（Terminate）を選択し、確認して実行します。 Terraformで新しいEC2を作成する準備 C:\Users\haruk\terraform-ec2-rds>terraform state list data.aws_vpc.lab IPアドレスは自動割り当てにしたいので、この部分を削除する。 private_ip = "10.0.1.122" ※terraformで指定するものしないもの必須項目：明示的な指定が必要任意項目：省略するとAWSやTerraformプロバイダーのデフォルト動作に従う AWS側の設定に依存する項目：サブネットなど、関連リソースの設定によって決まる ① 設定ファイルの構文チェック terraform validate ② 作成計画の確認 terraform plan 次のステップ：EC2を作成する terraform apply aws_instance.web: Creating... aws_instance.web: Still creating... [00m10s elapsed] aws_instance.web: Creation complete after 14s [id=i-08d91848fc7f1xxxx] Apply complete! Resources: 1 added, 0 changed, 0 destroyed. C:\Users\haruk\terraform-ec2-rds>terraform state list data.aws_vpc.lab aws_instance.web ←　Terraformが新しいEC2を管理する状態 terraformからEC2作成ができた！ここでセットした mariaDBがインストールされているかというと、、、 user_data = <<-EOF #!/bin/bash dnf install -y mariadb105 EOF sh-5.2$ mysql --version mysql Ver 15.1 Distrib 10.5.29-MariaDB, for Linux (x86_64) using EditLine wrapper sh-5.2$ ちゃんとインストールされていた！！新しいEC2から既存のRDSに接続する実習 sh-5.2$ mysql -h aws-lab-mysql.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com -P 3306 -u admin -p Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MySQL connection id is 1673 Server version: 8.4.11 Source distribution Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MySQL [(none)]> 既存のRDSに接続できた。
Zenn · Oct 23 · @otokichi3 · amazonlinux/amazon-linux-2023
【2026/10/23 12:00 時点】PHP2Shell の対応状況まとめ：PHP 本体、Linux、レンタルサーバ、KUSANAGI tyamadadd さんの記事「【速報：2026/10/22 04:00】PHP2Shellの対応状況まとめ：PHP本体、Linux、レンタルサーバ、KUSANAGI」がとても役に立ったので、同じ構成で 10月23日 12:00 時点の状況に更新しました。元記事の時点から状況が変わった箇所には「更新」と書いています。 ! 2026年10月23日 12:00（日本時間）時点の情報です。作業の前に、各行の出典で最新の状況を確認してください。確認の方法この記事は、生成 AI が調査と執筆を行いました。記事中の事実は、生成 AI が次の方法で一次情報と照合しています。 10月23日 11:47〜12:16 に、表の各行の出典を直接取得し、版番号、日時、記述を突き合わせたディストリビューションの状況は、Web ページだけでなく、機械可読のデータでも確認した Red Hat：CSAF VEX Ubuntu：CVE と USN の JSON AlmaLinux：errata の JSON Fedora：bodhi の API Alpine：secdb Sury：リポジトリの Packages ファイル出典を取得できなかった項目は、記事に載せていない。告知に書かれていないことは「明示なし」「未確認」と書いている日時は日本時間に換算した。元の時刻が UTC などのものは、換算した時刻だけを書いている取得した時点で、12:00 より後の更新はエックスサーバーの「10月23日 12:00 追記」だけでした。前回（10月22日 04:00）からの主な変化 PHP 公式から、再修正版や追加のアドバイザリは出ていない「8.5.12 の修正は不完全」という報告について、PHP のセキュリティチームが「RCE とは関係のない、影響の小さい別の問題」と回答した JPCERT/CC と IPA が注意喚起を出した。CISA の KEV（悪用が確認された脆弱性のカタログ）には登録されていない RHEL 10、RHEL 8、AlmaLinux、Rocky Linux、Amazon Linux 2023、Alpine v3.23、Debian unstable が修正済みになった。RHEL 9 は php:8.4 モジュールだけが未修正 Sury のリポジトリは、arm64 向けの多くがまだ修正前の版レンタルサーバは、ほとんどの事業者で修正の適用と管理画面の再開が終わった。KAGOYA と WebARENA は一部で停止が続いている KUSANAGI が、PHP 8.1 以前には修正版を出さないと明言した脆弱性の概要 2件とも、認証なしで遠隔から任意のコードを実行（RCE）される恐れがある脆弱性です。 PHP 公式は、どちらも CVSS v4.0 で 9.2（Critical）と評価しています。 CVE アドバイザリの題名内容 CVE-2026-109618（GHSA-w8hw-w9fx-j79w） RCE via OOM corruption メモリ不足（OOM）でリクエストの処理が途中で打ち切られ、初期化しきれていないデータを後片付けで扱ってしまう CVE-2026-109619（GHSA-6wmf-4rv5-p3rp） RCE via stale global state 直前のリクエストの内部状態が解放後も残り、同じワーカーが処理する次のリクエストが解放済みの領域を参照してしまう GHSA-w8hw-w9fx-j79w によると、Apache の mod_php では、アプリケーションのコードが動く前の段階で攻撃が成立します。 FrankenPHP も、mod_php と同じ理由で影響を受ける可能性が高いとされています。 CVE-2026-109619 については、PHP セキュリティチームの oss-security への投稿が、mod_php と PHP-FPM の両方で認証なしの RCE が実証されたとしています。発見者の一つである Wiz Research の解説サイト php2shell.com は、PHP 5.4 以降のほぼすべての版が影響を受けるとしています。公的機関の注意喚起（更新）機関内容出典 JPCERT/CC 注意喚起 JPCERT-AT-2026-0033。10月22日に公開し、同日に「V. 侵害調査」の表現を一部修正 JPCERT/CC IPA 「PHPの脆弱性対策について（CVE-2026-109618、CVE-2026-109619：PHP2shell）」を10月22日付けで掲載 IPA CISA KEV 2件とも未登録（カタログの最終更新は 10月21日 23:04） KEV の JSON PHP 公式の対応状況 10月21日に公開された次の4つの修正版から、変化はありません。 News Archive 2026 の最新の記事は10月21日のセキュリティアドバイザリのままです。 2件の GHSA も、10月21日の公開から更新されていません。系統修正版備考 8.5 8.5.12 8.4 8.4.27 8.3 8.3.36 8.2 8.2.35 2026年12月31日にサポート終了（EOL）サポートが終わった 7.4、8.0、8.1 向けには、PHP 公式が最小限の修正ソース（minimal source-backports）を提供しています。自前でビルドしていない環境では、ディストリビューションや LTS ベンダーの修正パッケージを使います。 Linux ディストリビューションの対応状況ディストリビューションによっては、PHP の版の番号を上げずに修正だけを取り込みます（バックポート）。 php -v に出る版の番号ではなく、各アドバイザリに載っているパッケージの版で、修正済みかどうかを確認してください。ディストリビューション状況アドバイザリ、修正済みパッケージ出典 Ubuntu 26.10 / 26.04 / 24.04 / 22.04 修正済み USN-8948-1 26.10: php8.5 8.5.9-0ubuntu2.1 26.04: php8.5 8.5.4-0ubuntu1.5 24.04: php8.3 8.3.6-0ubuntu0.24.04.13 22.04: php8.1 8.1.2-1ubuntu2.28 USN-8948-1 Ubuntu 20.04 / 18.04 / 16.04 / 14.04 修正済み（ESM） USN-8948-2 20.04: php7.4 7.4.3-4ubuntu2.29+esm5 18.04: php7.2 7.2.24-0ubuntu0.18.04.17+esm14 16.04: php7.0 7.0.33-0ubuntu0.16.04.16+esm22 14.04: php5 5.5.9+dfsg-1ubuntu4.29+esm18 USN-8948-2 Debian 13（trixie）修正済み DSA-6574-1、php8.4 8.4.27-1~deb13u1 Debian Security Tracker Debian 12（bookworm）修正済み DLA-4848-1、php8.2 8.2.35-1~deb12u1 同上 Debian unstable 更新修正済み php8.4 8.4.27-1 同上 Debian testing（forky）未修正 php8.4 8.4.26-1 のまま同上 Debian 11 / 10 / 9 修正済み（Freexian の有償 ELTS） 11: ELA-1853-1（php7.4 7.4.33-1+deb11u14） 10: ELA-1854-1（php7.3 7.3.31-1~deb10u16） 9: ELA-1855-1（php7.0 7.0.33-0+deb9u26） Freexian ELTS Tracker RHEL 10 更新修正済み RHSA-2026:87070（php 8.3.36-1.el10_2） RHSA-2026:87071（php8.4 8.4.27-1.el10_2） Red Hat VEX、CVE ページ RHEL 9 更新一部修正済み RHSA-2026:87151（php 8.0.30-8.el9_8.1） RHSA-2026:87072（php:8.2、8.2.35-1） RHSA-2026:87079（php:8.3、8.3.36-1） php:8.4 モジュールは未修正同上 RHEL 8 更新修正済み RHSA-2026:87080（php:7.4、7.4.33-8） RHSA-2026:87073（php:8.2、8.2.35-1）同上 AlmaLinux 8 / 9 / 10 更新修正済み RHEL の再ビルド（ALSA-2026:87070 / 87071 / 87072 / 87079 / 87080）に加え、RHEL より先に全ストリームへ独自のバックポートを提供。10月22日 06:15 から本番リポジトリに公開 AlmaLinux ブログ、errata Rocky Linux 8 / 9 / 10 更新修正済み（RHEL と同じ範囲） RLSA-2026:87070 / 87071 / 87072 / 87073 / 87079 / 87080 / 87151 Rocky Linux errata Oracle Linux 8 / 9 / 10 修正済み（RHEL と同じ範囲） ELSA-2026-87070 / 87071 / 87072 / 87073 / 87079 / 87080 / 87151 Oracle Linux CentOS Stream 10 一部修正済み php 8.3.36-1.el10 は公開済み。php8.4 は 8.4.24-2 のままミラー CentOS Stream 9 一部修正済み php 8.0.30-9.el9 は公開済み。モジュール（8.2、8.3）の修正版は未公開ミラー Fedora 44 / 43 / rawhide 修正済み 44: php-8.5.12-1.fc44 43: php-8.4.27-2.fc43 rawhide: php-8.5.12-1.fc46 45 は testing リポジトリのみ（php-8.5.12-1.fc45） bodhi SUSE 更新一部修正済み SLES 15 SP7: php8 8.3.36-150700.3.24.1、php7 7.4.33-150400.4.81.1 SLES 16.0: php8 8.4.27-160000.1.1 SP4〜SP6-LTSS: php8、php7 とも修正済み SLES 16.1 / 16.2 の php8 は影響あり SUSE openSUSE Leap 15.6 / 16.0 / 16.1 未修正 php8 が影響あり同上 openSUSE Tumbleweed 修正済み php8 8.5.12-1.1 同上 Amazon Linux 2023 更新修正済み ALAS2023-2026-3301〜3304（php8.2〜8.5）。php8.1 は修正予定なし Amazon Linux Security Center Amazon Linux 2 更新一部修正済み ALAS2PHP8.2-2026-015（php8.2 Extra）。Core の php は修正予定なし同上 Arch Linux 修正済み ASA-202610-1（php 8.5.12-1）、ASA-202610-2（php-legacy 8.3.36-1） Arch Linux Gentoo 修正済み GLSA 202610-02（dev-lang/php 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 以上） GLSA 202610-02 Alpine Linux 更新修正済み edge / v3.24 / v3.23: php83 8.3.36-r0、php84 8.4.27-r0、php85 8.5.12-r0 v3.22: php82 8.2.35-r0、php83、php84 secdb（v3.23） RHEL 9 で PHP 8.4 のモジュールを使っている場合は、まだ修正版がありません。 VEX で RHEL の影響ありのまま残っているのは、RHEL 9 の php:8.4 と RHEL 6 だけです（CVE-2026-109619 では RHEL 7 も）。修正済みのストリーム（php:8.3 など）に切り替えるか、後述の緩和策を入れてください。このほか Red Hat は、Red Hat Hardened Images 向けに php 8.5.12 を RHSA-2026:87414 で出しています。 AlmaLinux の独自バックポートは、php-8.1.32-1.module_el9.8.0+326+528679fc.alma.1 のように、元の版の番号のまま末尾に .alma.1 が付きます。 AlmaLinux 8 では php:7.2 が既定のストリームで、PHP の版を選ばずに入れた場合はこれが入っています。 AlmaLinux のブログは、php -v ではなく rpm -q php-common で、ブログに載っている版と比べるよう案内しています。サードパーティのリポジトリ Remi Remi のリポジトリでは、EL10 の remi-safe にも修正版が入っていることを確認しました（更新）。 php82〜php85 の 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 に加えて、php80 の 8.0.30-21 と php81 の 8.1.34-6 も入っています。 10月22日 21:58 には、修正版のリリースを告知するブログ記事が出ました。 Sury Debian 向けの packages.sury.org と Ubuntu 向けの ppa:ondrej/php は、PHP 5.6 までさかのぼって修正を取り込んでいます。次の表は、Debian 12 / 13 の amd64 向けの版です。系統パッケージの版修正の入り方 8.2〜8.5 8.2.35-1、8.3.36-1、8.4.27-1、8.5.12-1 PHP 公式の修正版そのもの 8.1 / 8.0 8.1.34-9、8.0.30-25 修正パッチを追加 7.2〜7.4 7.2.34-66、7.3.33-35、7.4.33-31 修正パッチを追加 5.6 / 7.0 / 7.1 更新 5.6.40-105、7.0.33-93、7.1.33-81（10月22日に版が上がった）修正パッチを追加 arm64 では修正版が出そろっていません（更新）。 10月23日 12時台にリポジトリの Packages ファイルを確認したところ、arm64 向けでは次の系統が修正前の版のままでした。対象修正前の版のままの系統 Debian 12（bookworm）arm64 8.2（8.2.34-1）、8.3（8.3.35-1）、8.4（8.4.26-1）、8.0、8.1、5.6、7.0、7.1 Debian 13（trixie）arm64 8.2（8.2.34-1）、8.3（8.3.35-1）、8.4（8.4.26-1）、8.5（8.5.11-1）、8.1、7.2 運営者の Ondřej Surý 氏は、10月22日 04:30 の Issue #145 へのコメントで、arm 向けのビルドは QEMU で動かしているため時間がかかり、すべて終わるまで2日ほどかかる見込みとしています。 arm64 のサーバ（AWS の Graviton など）で Sury のパッケージを使っている場合は、apt policy php8.x-cli で版を確認してください。その他の実行環境（新規）環境状況出典 Docker 公式 php イメージ 8.5 のタグが 10月22日 03:58、8.2〜8.4 のタグが 06:57〜07:06 に更新済み（-apache のタグの最終更新時刻）。EOL の 8.1、7.4 のタグは対象外 Docker Hub FrankenPHP 修正版の PHP で作った v1.13.2 を、10月22日 03:19 に公開 GitHub Releases CloudLinux alt-php（5.2〜8.5）の修正版を、10月22日 09:07 に CloudLinux 7 / 8 / 9 の stable に公開。ea-php52〜85 も修正済み。10月23日 09:08 に、版の番号を PHP 公式にそろえた alt-php82〜85 を出した CloudLinux ブログ LiteSpeed（lsphp） Debian 12 向けのリポジトリに lsphp82〜85 の修正版（8.2.35 / 8.3.36 / 8.4.27 / 8.5.12）あり LiteSpeed のリポジトリ Docker の公式イメージを使っている場合は、docker pull し直してコンテナを作り直さないと修正が入りません。 CloudLinux の alt-php と ea-php は、版の番号を上げずに修正を取り込んでいます（例：alt-php85 8.5.11-5）。 CloudLinux は、rpm -q --changelog で CVE の番号を探して確認するよう案内しています。 10月23日の alt-php82〜85 は版の番号をそろえただけで、すでに修正版を入れたサーバでは追加の対応は不要とされています。レンタルサーバの対応状況共用のレンタルサーバでは、PHP 本体の更新は事業者が行います。利用者にできるのは、事業者の告知を確認することと、管理画面で選べる PHP の版をサポート中の系統（8.2〜8.5）へ切り替えておくことです。事業者状況（10月23日 12:00 時点）適用した版の明示出典エックスサーバー（シン、XServerビジネス、スターサーバーもほぼ同じ内容） 10月22日 06:45 に 8.2〜8.5、12:00 に 7.4〜8.1、14:00 に 5.6〜7.3 の全サーバーへ修正を適用。5.5 以下は修正を作成・検証中。管理画面などは再開済み（一部の機能と旧WEBメールはメンテナンス中）。23日 12:00 の追記で、管理画面にアクセスが集中し、表示されない、または遅いと案内なし（「公式の修正版や弊社独自の修正」）エックスサーバー、シン、ビジネス、スターさくらのレンタルサーバ 10月21日 23:00〜22日 06:30 に PHP の版を更新。選べる全版で対応済みで、サポートが終わった版にも修正を適用。22日 08:15 時点で、一部の機能を除き緊急メンテナンスを解除なしサポート情報、お知らせ、メンテナンス情報ロリポップ！ 10月22日 03:09 頃から一部サーバーでサイトの表示を止め、13時頃に再開。全サービス再開済み。全版で session.upload_progress を無効化 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12。7.4〜8.1 は公式の EOL 版向けの修正、5.3〜7.3 は独自の修正ロリポップ！ヘテムル 10月22日 03:05 頃から一部サーバーでサイトの表示を止め、11:24 に再開。全サービス再開済み。全版で session.upload_progress を無効化 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12。5.6〜7.3 は独自の修正ヘテムル KAGOYA レンタルサーバープランは 7.4、8.1〜8.5 を修正版へ順次更新中で、「10月22日 24時には完了を見込む」。完了の告知はまだない。マネージド専用、共用、WordPress専用の各プランは方針を調整中。会員サイトとコントロールパネルは 22日 14:15 から、サポートサイトは 15:15 から停止中（終了は未定）なし影響について、コントロールパネルの停止、サポートサイトの停止 IDC フロンティア（Zenlogic）作業完了。7.4、8.1〜8.5 のサーバーは 22日 08:00 に Web サーバー（Apache）を再開。5.3 は最新版へ上げ、5.3 には戻せない。7.4、8.1 は修正パッチを適用、ほかの版はマイナーバージョンアップなし Zenlogic ConoHa WING 10月22日 20:45 に全対応が完了版の番号を上げずに修正を取り込んだ。表示は 8.5.11、8.4.26 などのまま ConoHa WING お名前.com レンタルサーバー対応完了。ConoHa WING と同じ内容同上お名前.com mixhost 10月22日 10:18 頃に、5.2〜8.5 の全サーバーで修正パッケージ（CloudLinux）を適用版の番号は変わらない（例：8.4.26） mixhost カラフルボックス 10月22日 07:35 に全サーバーで作業が完了。8.2〜8.5 は修正版へ、7.4〜8.1 などにも修正を適用なし（版を維持したまま更新）お知らせ、サーバーステータスバリューサーバー、CORESERVER、XREA、One レンタルサーバー提供中の全版で修正を適用済み。バリューサーバーは 22日 00:00〜00:50 に作業なしバリュードメイン、メンテナンス情報 WebARENA SuiteX / SuiteS 10月22日 18:00 から Web アクセスを順次停止。8.3 は 8.3.36 へ更新し、停止しない。2025年11月18日以前に開通した 7.4 と、7.2、5.6、5.3、5.1 は、修正パッチを適用できないため有効な対処ができるまで停止。契約管理画面などの再開は未定 8.3.36 WebARENA 元記事の表にあった「さくらの VPS のメンテナンス（22日 18:00 頃まで）」は、別の脆弱性（CVE-2026-99999）への対応で、PHP とは関係ありませんでした（メンテナンス情報）。さくらは「VPS はサービス提供に関わる部分で PHP を使っていないため影響なし」としています。 KAGOYA の告知は URL が変わりました。元記事のリンク先（2026102137094）は 404 で、現在は 2026102237094 です。未対応のプランでは、暫定策としてサイトの公開停止やアクセス制限（.htaccess に Deny from all）を検討するよう求めています。 ConoHa WING、お名前.com、mixhost、カラフルボックスなどは、修正を取り込んでも表示される版の番号が変わりません。 phpinfo() や WordPress のサイトヘルスに出る版の番号だけで「未修正だ」と判断しないでください。被害の公表について、告知の記述は次のとおりです。ロリポップ！とヘテムル：「脆弱性を狙ったとみられるアクセスの試みは確認されたが、不正アクセスや情報漏えいは現時点で確認されていない」さくら：「10月22日 14時現在、不正アクセスや情報漏えい等の被害は報告されていない」 KAGOYA：「攻撃や情報漏えい等の被害は確認されていない」エックスサーバー：管理画面などの停止は「不正アクセスの発生に伴うものではない」とだけ書いている。利用者のサーバーでの被害には触れておらず、「利用状況によっては追加の対策をお願いする場合がある」という文言を残している KUSANAGI の対応状況 8.2〜8.5 の修正パッケージは、10月22日の未明までにすべて出ています。系統 Enterprise / Security Edition Business Edition、KUSANAGI 9、Page Speed Technology 8.5 kusanagi-php85 8.5.12-1.el9（22日 01:14） kusanagi-php85 8.5.12-1（01:43） 8.4 kusanagi-php84 8.4.27-1.el9（22日 00:25） kusanagi-php84 8.4.27-1（00:51） 8.3 kusanagi-php83 8.3.36-1.el9（22日 03:00） kusanagi-php83 8.3.36-1（03:25） 8.2 kusanagi-php82 8.2.35-1.el9（22日 02:11） kusanagi-php82 8.2.35-1（02:37）脆弱性情報には「autoupdate コマンドでミドルウェアの自動更新を有効にしている場合、この修正は自動的に適用されます」とあります。有効にしていない場合は、手で dnf upgrade を実行してください。更新：10月23日 11:22 に「PHPの重大な脆弱性への対応とサポート終了済みPHPに関するご案内」が出ました。今回の更新は 8.2〜8.5 が対象で、8.1 以前にはセキュリティアップデートを提供しないサポート対象の PHP への版上げか、kusanagi migrate コマンドでの新しい環境への移行を勧めているそれまでの暫定策として WAF を勧めているが、脆弱性そのものを直すものではないとしている出典は KUSANAGI の RSS です（更新情報のページは機械的な取得ができなかったため、同じサイトの RSS で本文と公開時刻を確認しました）。修正版を適用できるまでの緩和策 PHP 公式のセキュリティアドバイザリは、緩和策を「特定の攻撃経路を減らすだけで、インストールを安全にするものではない」としています。 RHEL 9 の php:8.4、openSUSE Leap、Debian testing、Sury の arm64、KUSANAGI の 8.1 以前のように修正版がない環境で、移行までのつなぎとして使ってください。対象設定緩和できる範囲 CVE-2026-109618 memory_limit=-1（FPM プールの php_admin_value など、アプリから上書きできない場所で設定） PHP のメモリ上限による失敗をなくす。メモリ確保そのものの失敗は残る CVE-2026-109618 post_max_size を小さくする（アップロード不要なら 8M、必要でも 32M）大きなリクエストによる OOM を減らす CVE-2026-109619 session.upload_progress.enabled=0 確認済みのセッションの経路だけ CVE-2026-109619 fatal_error_backtraces=0（PHP 8.5 のみ）致命的エラー時のバックトレースを経由する、確認済みの経路だけ session.upload_progress.enabled=0 は php.ini か FPM のプール設定に書き、全ワーカーを再起動してください。ini_set() や .user.ini では効きません（PHP 公式のアドバイザリ）メモリに上限をかける手段として、RLIMIT_AS や RLIMIT_DATA を代わりに使わないでください。メモリ確保の失敗を起こし、脆弱な経路に入ります（GHSA-w8hw-w9fx-j79w）アップロード進捗の機能を使っていないなら、修正版へ更新した後もオフにしておくのが賢明だとされています（GHSA-6wmf-4rv5-p3rp）。ロリポップ！とヘテムルは、全サーバーでこの機能を無効にしました修正版を適用した後の侵害チェック修正版の適用は今後の攻撃を防ぐもので、適用より前に受けた侵入を元に戻すものではありません。 JPCERT/CC の注意喚起は、不審なプロセスの実行、外部への通信、不審なファイルの作成など、侵害の痕跡を確認し、継続的に監視するよう求めています。ログ：巨大な multipart/form-data のリクエストが集中していないか。PHP のワーカーの Segmentation Fault や異常終了が続いていないか不審なファイル：公開ディレクトリ（wp-content/uploads など）や一時ディレクトリに、見覚えのない .php ファイルがないかアカウント：WordPress などの CMS の管理者に、見覚えのないユーザーが追加されていないか権限：サーバが持つ権限（クラウドの IAM ロールやサービスアカウントなど）を確認し、横展開の有無を確かめる（GMO Flatt Security が挙げている）補足：「8.5.12 の修正は不完全」という報告のその後（更新）元記事では、Nicolas Krassas 氏（@Dinosn）の「PHP 8.5.12 security patch is incomplete（needs further validation）」という X の投稿を取り上げていました。同じ趣旨の報告は Fediverse でも出回り、次の2つの回答が出ています。 10月22日 05:33、Sury のリポジトリを運営する Ondřej Surý 氏が、Fediverse の報告を挙げた質問に「The PHP team is aware of that report and there are no new plans as of now.（PHP チームはその報告を把握しており、現時点で新たな予定はない）」と回答した（Issue #145） 10月22日 18:11、PHP セキュリティチームの Jakub Zelenka 氏が、oss-security で同じ Fediverse の報告に「This is unrelated issue with minimal impact (crash in one component in slightly unlikely scenario). It has nothing to do with the RCE.」と回答した（oss-security） PHP 側の回答は Fediverse の報告に対するもので、@Dinosn 氏の投稿を名指ししたものではありません。 10月23日 12:00 の時点で、新しい CVE や再修正版は出ていません。修正版への更新は予定どおり進めてください。アップロード進捗の機能を使っていなければ、session.upload_progress.enabled=0 にしておくのが安全です。出典・参考リンク各表の出典の列に載せたもの以外を中心に挙げます。元記事 tyamadadd：【速報：2026/10/22 04:00】PHP2Shellの対応状況まとめ：PHP本体、Linux、レンタルサーバ、KUSANAGI PHP 公式 PHP: News Archive 2026（予告、セキュリティアドバイザリ、緩和策） GHSA-w8hw-w9fx-j79w: RCE via OOM corruption GHSA-6wmf-4rv5-p3rp: RCE via stale global state oss-security: Re: CVE-2026-109619 注意喚起・解説 JPCERT/CC: JPCERT-AT-2026-0033 IPA: PHPの脆弱性対策について（PHP2shell） CISA: Known Exploited Vulnerabilities Catalog PHP2Shell（Wiz Research ほか） GMO Flatt Security: php2shell Linux ディストリビューション（表に載せた以外） Ubuntu: CVE-2026-109618 Red Hat：RHSA-2026:87070、RHSA-2026:87071、RHSA-2026:87072、RHSA-2026:87073、RHSA-2026:87079、RHSA-2026:87080、RHSA-2026:87151、RHSA-2026:87414 Amazon Linux 2023 の GitHub issue #1148（10月22日 16:17 にクローズ） Alpine secdb：edge、v3.24、v3.22 サードパーティのリポジトリ Remi's RPM repository、Remi のブログ DEB.SURY.ORG、ppa:ondrej/php、deb.sury.org Issue #145 KUSANAGI KUSANAGI 更新情報、RSS
Hacker News · Oct 22 · on Amazon identifies Oct 17 PHP2Shell exploitation prior to public disclosure · Tomdarkness · amazonlinux/amazon-linux-2023
So Amazon knew about this exploit and that it was actively being used several days before the release of any patches. Despite this they still took 18 hours AFTER the release of the patches to provide updated version of their Amazon Linux packages? amazon-linux-2023#1148 I don't think this blog post is sending the message AWS intended...
Hacker News · Oct 22 · on PHP web runtimes (CVE-2026-109618 and CVE-2026-109619) · HoyaSaxa · amazonlinux/amazon-linux-2023
Poor showing from AWS especially since Wiz’s blog post explicitly mentions that AWS was given advance notice. But they did in fact release the updated Amazon Linux image about 15 minutes ago: amazon-linux-2023#1148
Bluesky · Oct 21 · @twil-sere.bsky.social · amazonlinux/amazon-linux-2023
Amazon Linux とかいう今の時代の早さに付いて来れない信頼できない OS を使っている人は、もはや情弱と言ってよいと思うのだけれど。 amazon-linux-2023#1148
Reddit · Oct 21 · r/hypeurls · u/TheStartupChime · amazonlinux/amazon-linux-2023
AWS rates PHP RCE as Important so Amazon Linux 2023 patch may take 20 days
1 point
Bluesky · Oct 21 · @hackernewsbot.bsky.social · amazonlinux/amazon-linux-2023
AWS rates PHP RCE as Important so Amazon Linux 2023 patch may take 20 days | Discussion
1 like
Bluesky · Oct 21 · @drif.bsky.social · amazonlinux/amazon-linux-2023
If you ever need convincing to stay far the fuck away from Amazon Linux this thread and the complete void of any useful communication tells you everything you need to know amazon-linux-2023#1148
1 like
X · Oct 21 · @danipon0225 · amazonlinux/amazon-linux-2023
Amazon Linux 2023のPHP最新版が来なくてGitHub大荒れの巻 amazon-linux-2023#1148
4 likes · 1 repost · 2,605 views
Hacker News · Oct 21 · on AWS rates PHP RCE as Important so Amazon Linux 2023 patch may take 20 days · hayd · amazonlinux/amazon-linux-2023
comment in question: amazon-linux-2023#1148

Trending awards, every completed day and week

Gold: 01st place finishes
Silver: 02nd place finishes
Bronze: 03rd place finishes
Awarded repositories: 0Owned by amazonlinux now

No trending awards yet

None of the repositories amazonlinux owns has finished in the top three of a completed trending day or week, by stars, forks or PR authors. See who is trending now.

A repository earns an award for finishing first, second or third in a completed trending day or week, ranked by new stars, new forks or pull request authors. Awards follow a repository through renames and transfers and count toward its current owner. Weeks run Monday to Sunday, UTC.